- From: Mike Shaver <mike.shaver@gmail.com>
- Date: Fri, 14 May 2010 10:37:42 -0400
- 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. Mike
Received on Friday, 14 May 2010 14:38:16 UTC