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

Re: [Public WebGL] standalone typed array spec




On Jan 26, 2010, at 1:13 AM, Vladimir Vukicevic wrote:

I've got a standalone typed array spec pulled out here: http://people.mozilla.com/~vladimir/jsvec/TypedArray-spec.html

It still needs a decent amount of work, but I think it conveys the basic idea.  Brendan Eich has suggested that I send this to the es-discuss list (ecmascript group) and to put a strawman proposal up for them to discuss during their meetings this week; I'll do that as well to get their feedback and thoughts.  It would be interesting to have this functionality be a core part of ES, or at least as part of a standard library of some kind.

Comments:

1) I really liked the table in 5.14.3, which BYTES_PER_ELEMENT rather than 'Size', or have some other way to relate these two.

2) I'd like to see the WebIDL for everything

3) I think slice() should definitely return a reference to the original ArrayBuffer. You show the code you'd use make a copy, which I think is sufficient.

4) There is a good way to copy an ArrayBuffer:

var newBuf = (new Int8Array(otherArray.slice(1,10))).buffer;

Isn't that sufficient?

5) I think endianness will be the biggest issue here. I think we need a way to load data into the array in a machine independent way. For instance, there should be a way to put an array of bytes into a FloatArray, when the bytes are in different orders, like big, little endian and network order. I like using the term "network order" because I never remember if that's big or little endian. Maybe a serialize/deserialize semantic could be used? For instance:

var bytes; // data from the network
var floats = new FloatArray(bytes, NetworkOrder);
var outBytes = new ByteArray(floats, NetworkOrder);

Some or all of the Array classes would have a new ctor which would take a ByteArray (or UnsignedByteArray?) and an enum saying it's byte order. Likewise ByteArray would have a ctor which would take any of the other types and an enum. Would that be enough?


My biggest concern about this is getting it out the door quickly. Is ECMA the way to do that? Would it be better as a W3C recommendation?

-----
~Chris