W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2010

Re: Adoption of the Typed Array Specification

From: Vladimir Vukicevic <vladimir@mozilla.com>
Date: Fri, 14 May 2010 14:55:22 -0700 (PDT)
To: Kenneth Russell <kbr@google.com>
Cc: arun@mozilla.com, es-discuss@mozilla.org, public-script-coord@w3.org, Erik Arvidsson <erik.arvidsson@gmail.com>, Alex Russell <alex@dojotoolkit.org>
Message-ID: <976584657.191326.1273874122457.JavaMail.root@cm-mail03.mozilla.org>

----- "Kenneth Russell" <kbr@google.com> wrote: 


On Thu, May 13, 2010 at 10:21 PM, Alex Russell <alex@dojotoolkit.org> wrote: 
> On May 13, 2010, at 5:15 PM, Vladimir Vukicevic wrote: 
> 
>> This is difficult to do, given the goals of typed arrays -- they wouldn't behave like normal Arrays in most meaningful ways. 
> 
> Sounds like a bug to be fixed ;-) 
> 
>> At the core, an ArrayBuffer is of fixed size, and it doesn't make sense to index an ArrayBuffer directly (because there's no indication of what format the data should be accessed in). Making the array view types instances of Array might work, but again given that they're fixed length, there's a significant difference there. 
> 
> 
> That the length property of a particular array subclass leaves the constructor non-configurable and read-only isn't much of a trick in ES5. That said, why *doesn't* TypedArray spec a mutable variant? Surely it'd be useful. 

push(), and mutation of the length in general, are ill-defined when 
there are multiple views of the same region. Consider this simple case 
of two arrays referencing disjoint regions of an ArrayBuffer. While it 
is simple, it maps directly to many uses in OpenGL and WebGL programs, 

var buf = new ArrayBuffer(2 * Int16Array.BYTES_PER_ELEMENT + 4 * 
Int32Array.BYTES_PER_ELEMENT); 
var shorts = new Int16Array(buf, 0, 2); 
var ints = new Int32Array(buf, 2 * Int16Array.BYTES_PER_ELEMENT, 4); 

What happens if shorts.push(value) is called? Is the starting point of 
the Int32Array moved out to make room for the new element? If so, does 
the ArrayBuffer grow? Or does the Int16Array simply reference more of 
the storage of the existing ArrayBuffer? 

The other issue here is if the ArrayBuffer itself can change size -- growth has the problem of potentially needing to reallocate the storage, as was pointed out, but all views can be updated to point to the new storage. But if it shrinks, e.g. "buf.length = 2;" above, the views that are already depending on it would become illegal. The views make changing the arraybuffer size problematic. 

- Vlad 
Received on Friday, 14 May 2010 21:56:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:02 UTC