[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] TypedArrays request.responseArrayBuffer, servers and endianness
----- 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.
> 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.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: