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

Re: Adoption of the Typed Array Specification

From: Mike Shaver <mike.shaver@gmail.com>
Date: Fri, 14 May 2010 10:37:42 -0400
Message-ID: <AANLkTil04Ntp9yry8ypRO3NYlHZkCsw-18SI8qFhnLKX@mail.gmail.com>
To: Chris Marrin <cmarrin@apple.com>
Cc: Oliver Hunt <oliver@apple.com>, arun@mozilla.com, es-discuss@mozilla.org, public-script-coord@w3.org, Erik Arvidsson <erik.arvidsson@gmail.com>
On Fri, May 14, 2010 at 10:30 AM, Chris Marrin <cmarrin@apple.com> wrote:
> As Ollie mentioned, ArrayBuffers need to be able to be mapped to hardware storage (either on the CPU or GPU). So anything that might change the underlying storage address (such as resizing the array) would be problematic.

Resizing might invalidate some addresses, yes, but it seems like those
mappings aren't necessarily fixed for the lifetime of the object.  I
can create an ArrayBuffer and then do a bunch of stuff with it before
I ever hand it to WebGL, even today -- why should we make authors
manually create a new AB and copy?

Aren't these buffers allocated and deallocated and copied by C
programs, too?  It might be that extending an ArrayBuffer doesn't give
you the semantics you want, just as realloc might fail if you aren't
careful about updating the hardware mappings.  I presume that people
use malloc (or the VBO/etc. equivalent) to create them, and can
realloc to their heart's content as long as they don't break their
contract with the places they've passed it to.

Received on Friday, 14 May 2010 14:38:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:02 UTC