[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Public WebGL] TypedArrays request.responseArrayBuffer, servers and endianness


I'm developing a Java server-side library to prepare data for consumption by webgl. To be clear, I want to create arrays of bytes on the server which correspond to data structures in GL, for example, VBOs. My current implementation works, but requires a rather pointless and time-consuming serialization to text and back.

I'm therefore interested in the mozResponseArrayBuffer extensions to XHR and also the 'request.responseArrayBuffer' - the 'imaginary API' mentioned by Chris Marrin on this thread http://www.khronos.org/webgl/public-mailing-list/archives/1005/msg00055.html. My questions relate to the fact that the TypedArray specification avoids mentioning endianness for any part of the ArrayBuffer and TypedArray definitions and only discusses byte order in the DataView. Even the example given to show how altering the byte view and the uint16 view uses 0xffff and thus avoids any discussion of byte order.

I want to create streams of bytes on the server which are explicitly the byte streams corresponding to the data actually input to gl functions such as bufferData(...)

Sample code would therefore be functionally equivalent to:

var xhr = new XMLHttpRequest();
xhr.open("GET", "index_file", false);
buffer = xhr.mozResponseArrayBuffer;
if (buffer) {
  var vboData= new UInt16Array(buffer);
  gl.bufferData(ELEMENT_ARRAY_BUFFER, vboData, STATIC_DRAW);

My understanding is that the TypedArray specification was designed to reduce the effort on the JS side of feeding data into GL. It seems that the approach in the spec. is to simply ignore byte-order - assume that the byte-order "sorts itself out" because the client  creating the buffer will have the correct byte order for the machine.

I think I understand the purpose of the DataView as being an API which allows byte order conversion when data is streamed in from the disk or network. Actually, my intention is slightly different. I intend for the *server* to provide the client with data in the correct byte order. So, in effect, something corresponding to the DataView would be used on the server. There are thus four cases to cope with, depending upon the endianess of the server and the client.

As it happens, by default, regardless of the endianness of the server h/w, Java actually stores its data in a big-endian format so for my specific library I probably really only need to know that the client is little-endian. It seems to me that I will need to possibly create two versions of every object - one in BE and the other in LE - although I suspect that the BE form should probably be created on demand.

My questions/points are:

1. Am I right? The TypedArray spec is written as byte-order agnostic? It will work on either byte-order client?
2. There is no mechanism in the TypedArray spec to indicate what the 'native order' is for the current client and none planned.
3. Does anyone know a way of reliably determining from within a _javascript_ client the native byte order?
4. The DataView assumes that you know which byte-order the client requires.

A bit off-topic, but also does anyone know what the native byte order is for Android?