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

Re: [Public WebGL] standalone typed array spec



On 1/26/2010 7:30 AM, Chris Marrin wrote:

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.

It made the table ugly :-)  The sentence right above the table stats that the size is equivalent to the BYTES_PER_ELEMENT constant -- is that enough?

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

Yeah, I wanted to wait until we saw where this would land, though I guess no matter what we'd have to have some WebIDL to describe the interface that the types should conform to..

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.

My worry is that the semantics are different with this slice and normal Array.slice() -- Array.slice() will return a copy that you can then modify without changing the original, whereas this wouldn't.


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

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

Isn't that sufficient?

It is, but pretty ugly and convoluted.  Adding a slice() method to ArrayBuffer would work though, what do you think?

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?

I was actually thinking about methods like fromLittleEndian(), fromBigEndian(), fromNetworkEndian(), and the opposite toLittleEndian etc.  That would convert the data based on intent ("I have big endian data and I want it in the platform endian").  Though I'd once again fall back on a generic byteSwap(), since from/to don't give you a way to just say "I want data in opposite-endian to what it is now".  fromOtherEndian/toOtherEndian? :-)

I don't really like having a constructor for it, because it would mean that the constructor actually does work -- all the other constructors just create a view and don't touch the actual data.  Something like:

  var ints1 = new Int32Array(bytes, NetworkOrder);
  var ints2 = new Int32Array(bytes, NetworkOrder);

Would end up swapping the array twice, which seems unexpected to me.

Hmm, or are you suggesting that the byte swapping be done at access time?  Now that I think about it, that might be required -- otherwise you couldn't access a complex data structure (e.g. packed ints, shorts, etc.) because you wouldn't be able to easily say "byte swap all the ints" or somesuch.

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?

That's my concern as well -- Brendan and Arun suggested that we try ECMA first, and if it doesn't look like they're interested and/or if they can't move quickly, then look at alternatives.  The problem was that it didn't really seem to fit into any of the W3C groups; the WebApps group is probably the closest as a catch-all, but I don't think its charter would encompass something like this.  A new group could certainly be started, but that's even more time..

    - Vlad