[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] standalone typed array spec
On Jan 26, 2010, at 10:03 AM, Vladimir Vukicevic 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.
>> 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?
Yeah, I think that's fine.
>> 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.
So then it's just a naming issue. I wonder if we even need slice() at all. For this array:
var a = new FloatArray([1,2,3,4,5,6,7,8,9,10]);
var b = a.slice(5,3);
is the same as this:
var b = new FloatArray(a.buffer, 5, 3);
Is that really so hard?
>> 4) There is a good way to copy an ArrayBuffer:
>> var newBuf = (
>> Isn't that sufficient?
> It is, but pretty ugly and convoluted. Adding a slice() method to ArrayBuffer would work though, what do you think?
Now there slice() would have the same semantics as for Array, right? So that seems reasonable.
>> 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.
The thing I don't like about byteSwap() is that it requires you know what the native endianness is and that it's not the endianness you want. With fromNetworkOrder()/toNetworkOrder() methods it might not do any swapping at all, and the author doesn't have to worry about that. They just know what their source data is (big/little/network) when they're bringing the data in and they know what they want when they're sending the data out.
I like the idea of only letting the author fiddle with this on the way in or out. That discourages "cleverness" on the part of the author in playing with endianness. It doesn't prevent it, it just makes an author think twice before doing it. Endianness issues arise when data is coming into your system from the outside which may (or may not) have different endianness.
>> 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.
I'm not sure we need a group, formally. We didn't have one for all the CSS Effects specs we did. We just wrote them, did an implementation and then started talking to css-style. That was a nice home for them of course. But I think the most important thing is to have a formal spec people can link to for discussion. There are already several groups talking about using them (the various audio efforts and one other I saw somewhere). So for now maybe we can just create a formal spec and put it on our public wiki. Then we can implement it in WebKit (and therefore Chrome) and Mozilla so people doing these other efforts can have access to the latest stuff. I think everything else will fall into place after that.
You are currently subscribe to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: