[Public WebGL] standalone typed array spec

[Vladimir Vukicevic]

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 
>> <http://people.mozilla.com/%7Evladimir/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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20100126/5a3a50ec/attachment.html>