[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] TypedArrays request.responseArrayBuffer, servers and endianness
On 09/29/2010 12:08 PM, Oliver Hunt wrote:
On Sep 29, 2010, at 12:00 PM, firstname.lastname@example.org wrote:
On 09/29/2010 11:12 AM, Oliver Hunt wrote:I know that was what you were asking, and what i was saying is that that problem is specific to data transfer which is outside of the scope of webgl, and is something that needs to be handled in the XHR (or whichever) specifications, eg. the specification that actually relate to data transfer.
So if I fill a buffer with bytes that represent 'int32' data on the server how do I know which byte order the client expects the data to be in? That was the point of my original question. I realize that I can *assume* that byte order is little-endian for most common web browser implementations on Intel platforms. Obviously, I can also read headers from the request to determine the browser/OS - but that's hit and miss.
I believe that the byte order for data transfers will need to be determined as part of the xhr/html5 specs rather than as part of webgl as webgl does not it self describe any network/io level details.
To avoid byte order issues purely on the client side it is important to not try to use any tricks when writing down data. eg. if you want to fill a buffer with inidividual bytes you should use a byte array, if you want to store int32s you should use an int32 view, etc. Otherwise you open up the possibility of byte order problems on the client side.
Agreed - sorry if I misunderstood what you were getting at.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: