[Public WebGL] standalone typed array spec

Kenneth Russell [email protected]
Tue Jan 26 13:00:26 PST 2010

On Tue, Jan 26, 2010 at 10:03 AM, Vladimir Vukicevic
<[email protected]> wrote:
> 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?

This doesn't work -- the resulting buffer will be the same as "otherArray"'s.

A slice() method on ArrayBuffer would work.

> 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.

It's certainly necessary to do the byte swapping at the time of the
call to get/set, because the ArrayBuffer contains heterogeneous data.

With the ArrayBuffer type in place, we can define new views on it. We
could define a NetworkStream view which has a cursor, and which allows
all of the various primitive types to be read or set at the cursor
position, in either big-endian or little-endian order. The Java NIO
classes have this concept, only it is tied up in the bottommost class
(Int8Array in this case).


> 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

You are currently subscribe to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:

More information about the public_webgl mailing list