[whatwg] Endianness of typed arrays

[Boris Zbarsky]

On 3/28/12 3:14 AM, Mark Callow wrote:

 > vertexAttribPointer lets you specifiy to WebGL the layout and type of
 > the data in the buffer object.

Sure.  That works for the GPU, but it doesn't allow for the sort of 
on-the-fly endianness conversion that would be needed to make webgl 
still work on big-endian platforms if the JS-visible typed arrays were 
always little-endian.

 > The API follows OpenGL {,ES} for familiarity and reflects its
 > heritage of a C API avoiding use of structures.

Yep.  I know the history.  I think this was a mistake, if we care about 
the web ever being usable on big-endian hardware.  Whether we do is a 
separate question.

 > But it works.

Sort of, but maybe not; see below.

> OpenGL {,ES} developers typically load data from a serialized form and
> perform endianness conversion during deserialization. The serialized
> form is what would be loaded into an ArrayBuffer via XHR. It is then
> deserialized into 1 or more additional ArrayBuffers.

The point is that developers are:

1)  Loading data in serialized forms that has nothing to do with WebGL
     via XHR and then reading it using typed array views on the
     resulting array buffer.
2)  Not doing endianness conversions, either for the use case in point
     1 or indeed for WebGL.

Again, I think we all agree how this would work if everyone using the 
typed array APIs were perfect in every way and had infinite resources. 
But they're not and they don't... The question is where we go from here.

In practice, it sounds like a UA on a big-endian system has a few options:

A)  Native-endianness typed arrays.  Breaks anyone loading data via XHR 
arraybuffer responses (whether for WebGL or not) and not doing manual 
endianness conversions.

B)  Little-endian typed arrays.  Breaks WebGL, unless developers switch 
to a more "struct-based" API.  Makes the non-WebGL cases of XHR 
arraybuffer responses work.

C)  Try to guess based on where the array buffer came from and have 
different behavior for different array buffers.  With enough luck (or 
good enough heuristics), would make at least some WebGL work, while also 
making non-WebGL things loaded over XHR work.

In practice, if forced to implement a UA on a big-endian system today, I 
would likely pick option (C)....  I wouldn't classify that as a victory 
for standardization, but I'm also not sure what we can do at this point 
to fix the brokenness.

-Boris