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

Re: [Public WebGL] ArrayBuffer, Concatenation and String-Array Conversion, a proposal

See comments below:

On 10/05/2010 02:04 PM, Samuel Kleiner wrote:
The question here is why isn't there a function for doing these conversions between JavaScript Strings and Arrays? I suppose the answer is that it's not common enough; storing a unicode value in an array isn't done very much.
I think it will be.

My use case here would be to send, as single JSON file, a complete 3d model in a format parsable by javascript. In the ideal case, that 3d model could include shader code, and binary data. JSON can be parsed using the built-in accelerated function for doing so, but then you need a way of transforming likely large blocks of text to array buffers.
If you have a vertex array, for example, this will be at the very least a sequence of floating point numbers. You may also have data in some other format - eg colors as bytes.

in the 'real world' a floating point number to represent a vertex or a texture coordinate probably represents maybe 6 or 7 characters + at least one separating character, so probably at least 8 characters (which may be 2 bytes) per fp.

You can send exactly the same data with 4 bytes per FP and 1 byte per color using the (moz)'responseArrayBuffer' or even by packing binary into an ASCII response

In many applications the vertex data doesn't change. It makes sense to cache such a file on the server and allow the browser to cache it as well. I've already tried this and it works extremely well.

If people were to choose to signed vertex (or animation) data as large blocks of strings then there are already mechanisms for handling those.

Also, if you parse a very large JSON object surely you end up with all the data required for the object allocated. It seems to me that a much better practice is to separate out that data which will be passed into the GL and keep as few copies of that in memory as possible. By making an ArrayBuffer a cacheable item it can be stored on the server, or in the local cache, passed to the GL and the in-memory client copy deleted because its no longer required, thus reducing the memory footprint.
So JS functions which loop over the string, calling charCodeAt() for each character, give you a reasonable solution. I'm not sure why that would not be a reasonable solution here as well. I'm not sure your example would be commonly used. Assuming we get the ability to read an ArrayBuffer from XHR, the better way to load large vertex data will be to load the binary data directly.

Totally agree.


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: