W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2011

[whatwg] ArrayBuffer and the structured clone algorithm

From: Simon Pieters <simonp@opera.com>
Date: Tue, 01 Feb 2011 11:19:55 +0100
Message-ID: <op.vp7yzhleidj3kv@simon-pieterss-macbook.local>
On Tue, 01 Feb 2011 07:47:26 +0100, Kenneth Russell <kbr at google.com> wrote:

> On Mon, Jan 31, 2011 at 3:10 PM, Ian Hickson <ian at hixie.ch> wrote:
>> On Fri, 7 Jan 2011, David Flanagan wrote:
>>> The structured clone algorithm currently allows ImageData and Blob
>>> objects to be cloned but doesn't mention ArrayBuffer.  Is this
>>> intentional?  I assume there are no security issues involved, since one
>>> could copy the bytes of an ArrayBuffer into either a Blob or an
>>> ImageData object in order to clone them.
>> It's intentional in that I'm waiting for ArrayBuffer to be more stable
>> before I add it throughout the spec. (Same with CORS and the various
>> places that might support cross-origin communication, e.g. Web Workers,
>> Server-Sent Events, <img>+<canvas>, etc.)
> There's been some preliminary discussion within the WebGL working
> group (where ArrayBuffer / Typed Arrays originated) about using
> ArrayBuffer with Web Workers in particular. There is a strong desire
> to support handoff of an ArrayBuffer from the main thread to a worker
> and vice versa; this would allow efficient producer/consumer queues to
> be built without violating ECMAScript's shared-nothing semantics.
> All of the parties involved are pretty busy getting WebGL 1.0 out the
> door; once that happens, we aim to make one more revision to the Typed
> Array spec to support (1) read-only arrays for more efficient XHRs and
> (2) handoff of ArrayBuffers. Expect public discussions to start in
> about six to eight weeks.

While you're discussing efficient handoff of ArrayBuffer, do you also keep  
in mind efficient handoff of other objects (e.g. ImageData) as discussed  
in this thread?:  

Simon Pieters
Opera Software
Received on Tuesday, 1 February 2011 02:19:55 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:30 UTC