[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 02:37 PM, Vladimir Vukicevic wrote:

----- Original Message -----
The whole point of the DataView is to avoid hackery in trying to
figure out the endianness of the machine. I can't imagine a case where
there would be a need to format the data on the server. "network byte
order" for internet protocols is big-endian. That doesn't mean you
need to ship your data in big-endian format, but your computer is
sending and receiving big-endian data constantly, so it needs to deal
with already.
Well... technically, your computer is just receiving bytes for the packet payload.  If you needed to communicate between two computers and couldn't agree on endianness in any way, then yeah, you should probably use big endian.  But for interpreting the raw application data, both ends of which are under your control, should be up to the application.  For this type of usage, reformatting the data on the server (or really, just keeping a big endian and little endian version on the server) is probably the fastest thing -- it'll give you exactly what you want to feed in to webgl directly.

This is what I was getting at in my original post. Since one of our (mechnicality's) major bottlenecks at the moment is the serialization/deserialization through text and also a needless copy due to a shortcoming in GWT, I'm very keen to experiment with the mozResponseArrayBuffer stuff ASAP.

It should be noted that these days keeping a few 10's of megabytes on a server is incredibly cheap, but serializing/deserializing the same data over and over again is a real waste of b/w and cpu - and I haven't noticed any mobile devices exactly being flush with memory, so avoiding as much copying there is a good thing as well.

You should pick an endianness and store all your data in that form on
the server. Then use DataView to access it and provide the endianness
flag that matches the endianness of the data. The implementation
should take care of the rest.
Yep, that would work (though Firefox doesn't yet implement DataView!), but given that you know the endianness of your client platform, you should be able to optimize this even more and skip using DataView entirely.
Well, skipping DataView entirely is a good move. I'm going to do some experiments over the next few days and I'll report back if anyone's interested.


You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: