This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24175 - Canvas Pixel ArrayBuffer should return RGBA for big-endian and ABGR for little-endian machines
Summary: Canvas Pixel ArrayBuffer should return RGBA for big-endian and ABGR for littl...
Status: RESOLVED INVALID
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks: 24177
  Show dependency tree / graph
 
Reported: 2013-12-29 22:03 UTC by contributor
Modified: 2013-12-31 06:00 UTC (History)
3 users (show)

See Also:

Attachments

Description contributor 2013-12-29 22:03:31 UTC 
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html
Multipage: http://www.whatwg.org/C#pixel-manipulation
Complete: http://www.whatwg.org/c#pixel-manipulation
Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/

Comment:
Canvas Pixel ArrayBuffer should return RGBA for big-endian and ABGR for
little-endian  machines

Posted from: 66.229.94.210
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36
Comment 1 Arthur Y 2013-12-29 23:34:40 UTC 
Providing the same order for both platforms is a behavior not consistent with Typed Arrays, which use the client's platform byte order. This inconsistency gives rise to bloated code and having to test for the platform order.

"A Canvas Pixel ArrayBuffer is an ArrayBuffer that whose data is represented in left-to-right order, row by row top to bottom, starting with the top left, with each pixel's red, green, blue, and alpha components being given in that order for each pixel." [1]

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-imagedata-data
Comment 2 Vladimir Vukicevic (Mozilla) 2013-12-30 03:18:11 UTC 
(In reply to Arthur Y from comment #1)
> Providing the same order for both platforms is a behavior not consistent
> with Typed Arrays, which use the client's platform byte order. This
> inconsistency gives rise to bloated code and having to test for the platform
> order.

I don't see an inconsistency -- the ImageData's data element is a Uint8ClampedArray, with the pixels' values coming explicitly in the order of R G B A, as individual bytes.  Endianness issues do not apply.  If you reach under and access the ArrayBuffer directly and create a new 32-bit view of the data, then yes, you are exposed to endianness issues; at that point that's just a general typed array situation, and is consistent with other typed array behaviour.  That's no different than mapping any arbitrary 8-bit data to 32-bit values.

This seems like it's INVALID to me, but maybe I'm misunderstanding the request?