Re: Adoption of the Typed Array Specification

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?

Now consider the case where the two arrays overlap. This is again
common usage in OpenGL programs; it is how interleaved vertex data is
constructed.

  var buf = new ArrayBuffer(16000);
  var shorts = new Int16Array(buf, 0, 1000);  // Room to grow
  var ints = new Int32Array(buf, 0, 500);

What happens if shorts.push() is called? In this case plausibly the
right answer is that the view grows toward the end of the ArrayBuffer.
This is probably a different answer than what seems obvious for the
first case above.

Adding all of ECMAScript arrays' semantics to these TypedArrays will
make it impossible to understand how they work. It will also likely
prevent them from performing well. They are currently implemented with
high performance in multiple browsers, and if that property is
destroyed then the WebGL working group will have to create another
specification to allow good performance to be achieved again.

-Ken

> Regards
>
> --
> Alex Russell
> slightlyoff@google.com
> alex@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>

Received on Friday, 14 May 2010 18:44:56 UTC