24175 2013-12-29 22:03:31 +0000 Canvas Pixel ArrayBuffer should return RGBA for big-endian and ABGR for little-endian machines 2013-12-31 06:00:47 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED INVALID http://www.whatwg.org/specs/web-apps/current-work/#pixel-manipulation P3 normal Unsorted 24177 1 contributor ian arthuryidi mike vladimir contributor oldest_to_newest 97881 0 contributor 2013-12-29 22:03:31 +0000 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 97883 1 arthuryidi 2013-12-29 23:34:40 +0000 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 97887 2 vladimir 2013-12-30 03:18:11 +0000 (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?