Re: [whatwg] ArrayBuffer and the structured clone algorithm
On Mon, Jan 31, 2011 at 10:47 PM, Kenneth Russell wrote: > On Mon, Jan 31, 2011 at 3:10 PM, Ian Hickson 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, +, 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. Apologies for not following up to this thread. Some strawman proposals for the typed array specification were posted about a month ago and updated just now based on initial feedback. The primary goal is to define interactions between the structured cloning algorithm and ArrayBuffers, so that zero-copy data transfer between Web Workers can be achieved. These proposals, if agreed upon, would involve changes to the structured cloning algorithm and Web Messaging spec. Please see: http://www.khronos.org/registry/typedarray/specs/latest/ Feedback would be greatly appreciated. There is an ongoing thread on the public WebGL mailing list ( see https://www.khronos.org/webgl/public-mailing-list/ ), but I'll take care of coalescing feedback from mailing lists. -Ken
Re: [whatwg] ArrayBuffer and the structured clone algorithm
On 5/9/11 6:44 PM, Ian Hickson wrote: For this reason I think we need to keep CanvasPixelArray distinct. I certainly hope that Web IDL does not change its conversion rules to mimic the clamping behavior in CanvasPixelArray. Right now Web IDL delegates to the ECMA-262 specification for primitive conversions, which have the wrapping behavior of C-style casts rather than clamping behavior. Forcing clamping for out-of-range integer values would impose a significant negative performance constraint on typed arrays. I haven't changed CanvasPixelArray. Note that Gecko implements CanvasPixelArray as a kind of typed array that has the right kind of behavior on assignment. This means that you can extract the array buffer as usual create other typed views of it, etc. We feel that there are significant benefits to doing this and would be interested in trying to get something like that standardized if others are interested as well. If not, of course, then we just keep our current behavior, but that does mean that CanvasPixelArray in Gecko has properties/methods not present in some other UAs -Boris
Re: [whatwg] ArrayBuffer and the structured clone algorithm
On Mon, 31 Jan 2011, Kenneth Russell wrote: > > 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. Ken and I discussed this off-list, editor-to-editor as it were, and the plan is to wait for Typed Arrays to settle down a bit more, and then once they are stable, to update the structured clone algorithm to handle them directly (so that the Typed Array spec doesn't have to be a delta spec to the HTML spec). On Tue, 1 Feb 2011, Boris Zbarsky wrote: > On 2/1/11 1:04 PM, Anne van Kesteren wrote: > > On Tue, 01 Feb 2011 18:36:19 +0100, Boris Zbarsky > > wrote: > > > For what it's worth, in Gecko that's the same thing, since imagedata > > > is just a typed array in our implementation. > > > > I wonder if we can still remove CanvasPixelArray. > > Well, the typed array we use is a custom type that implements the > CanvasPixelArray semantics (e.g. the rounding and clamping bits) On Tue, 1 Feb 2011, Oliver Hunt wrote: > > I haven't seen anything that depends on CanvasPixelArray the name, but I > wonder if people use the constructor to access the CPA prototype? It > could be treated simply as an alias to the appropriate Typed Array > constructor i guess, but i'd want to be sure that there's no weirdness > with people modifiying both the typed array and cpa prototypes. On Tue, 1 Feb 2011, Tab Atkins Jr. wrote: > > Only if the out-of-bounds behavior for entries in Typed Arrays matches > the current clamping behavior for CanvasPixelArray. I don't see any > explicit indication of what should be done in the Typed Array spec, > which I suppose means that they're relying on WebIDL's coercion algos to > keep things in-range for the given view. WebIDL has the wrong behavior > here right now (it wraps), though I think heycan is receptive to > changing it. On Tue, 1 Feb 2011, Kenneth Russell wrote: > > For this reason I think we need to keep CanvasPixelArray distinct. I > certainly hope that Web IDL does not change its conversion rules to > mimic the clamping behavior in CanvasPixelArray. Right now Web IDL > delegates to the ECMA-262 specification for primitive conversions, which > have the wrapping behavior of C-style casts rather than clamping > behavior. Forcing clamping for out-of-range integer values would impose > a significant negative performance constraint on typed arrays. I haven't changed CanvasPixelArray. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] ArrayBuffer and the structured clone algorithm
Anne van Kesteren: > > ImageData.data you mean? I wonder if we can still remove > > CanvasPixelArray. Tab Atkins Jr.: > Only if the out-of-bounds behavior for entries in Typed Arrays matches > the current clamping behavior for CanvasPixelArray. I don't see any > explicit indication of what should be done in the Typed Array spec, > which I suppose means that they're relying on WebIDL's coercion algos > to keep things in-range for the given view. WebIDL has the wrong > behavior here right now (it wraps), though I think heycan is receptive > to changing it. This is http://www.w3.org/Bugs/Public/show_bug.cgi?id=10930. Kenneth Russell: > For this reason I think we need to keep CanvasPixelArray distinct. I > certainly hope that Web IDL does not change its conversion rules to > mimic the clamping behavior in CanvasPixelArray. Right now Web IDL > delegates to the ECMA-262 specification for primitive conversions, > which have the wrapping behavior of C-style casts rather than clamping > behavior. Forcing clamping for out-of-range integer values would > impose a significant negative performance constraint on typed arrays. So it seems at this stage CanvasPixelArray definitely needs to have the clamping behaviour. If people have opinions on whether all JS Number → IDL integer type conversions should clamp or wrap, or whether Web IDL should just have an annotation to indicate what kind of conversion is used, please comment in the bug. Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] ArrayBuffer and the structured clone algorithm
On 01/02/2011, at 11:19, Simon Pieters wrote: > On Tue, 01 Feb 2011 07:47:26 +0100, Kenneth Russell wrote: >> On Mon, Jan 31, 2011 at 3:10 PM, Ian Hickson 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, +, 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?: > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029885.html > > cheers > -- > Simon Pieters > Opera Software Yes. Please. +1 Cheers, -- Jorge.
Re: [whatwg] ArrayBuffer and the structured clone algorithm
On 2/1/11 1:04 PM, Anne van Kesteren wrote: On Tue, 01 Feb 2011 18:36:19 +0100, Boris Zbarsky wrote: For what it's worth, in Gecko that's the same thing, since imagedata is just a typed array in our implementation. ImageData.data you mean? Yes. I wonder if we can still remove CanvasPixelArray. Well, the typed array we use is a custom type that implements the CanvasPixelArray semantics (e.g. the rounding and clamping bits) -Boris
Re: [whatwg] ArrayBuffer and the structured clone algorithm
On Tue, Feb 1, 2011 at 11:08 AM, Tab Atkins Jr. wrote: > On Tue, Feb 1, 2011 at 10:04 AM, Anne van Kesteren wrote: >> On Tue, 01 Feb 2011 18:36:19 +0100, Boris Zbarsky wrote: >>> >>> On 2/1/11 5:19 AM, Simon Pieters wrote: 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?: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029885.html >>> >>> For what it's worth, in Gecko that's the same thing, since imagedata is >>> just a typed array in our implementation. >> >> ImageData.data you mean? I wonder if we can still remove CanvasPixelArray. > > Only if the out-of-bounds behavior for entries in Typed Arrays matches > the current clamping behavior for CanvasPixelArray. I don't see any > explicit indication of what should be done in the Typed Array spec, > which I suppose means that they're relying on WebIDL's coercion algos > to keep things in-range for the given view. WebIDL has the wrong > behavior here right now (it wraps), though I think heycan is receptive > to changing it. For this reason I think we need to keep CanvasPixelArray distinct. I certainly hope that Web IDL does not change its conversion rules to mimic the clamping behavior in CanvasPixelArray. Right now Web IDL delegates to the ECMA-262 specification for primitive conversions, which have the wrapping behavior of C-style casts rather than clamping behavior. Forcing clamping for out-of-range integer values would impose a significant negative performance constraint on typed arrays. -Ken
Re: [whatwg] ArrayBuffer and the structured clone algorithm
On Tue, Feb 1, 2011 at 10:04 AM, Anne van Kesteren wrote: > On Tue, 01 Feb 2011 18:36:19 +0100, Boris Zbarsky wrote: >> >> On 2/1/11 5:19 AM, Simon Pieters wrote: >>> >>> 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?: >>> >>> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029885.html >> >> For what it's worth, in Gecko that's the same thing, since imagedata is >> just a typed array in our implementation. > > ImageData.data you mean? I wonder if we can still remove CanvasPixelArray. Only if the out-of-bounds behavior for entries in Typed Arrays matches the current clamping behavior for CanvasPixelArray. I don't see any explicit indication of what should be done in the Typed Array spec, which I suppose means that they're relying on WebIDL's coercion algos to keep things in-range for the given view. WebIDL has the wrong behavior here right now (it wraps), though I think heycan is receptive to changing it. ~TJ
Re: [whatwg] ArrayBuffer and the structured clone algorithm
On Feb 1, 2011, at 10:04 AM, Anne van Kesteren wrote: > On Tue, 01 Feb 2011 18:36:19 +0100, Boris Zbarsky wrote: >> On 2/1/11 5:19 AM, Simon Pieters wrote: >>> 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?: >>> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029885.html >> >> For what it's worth, in Gecko that's the same thing, since imagedata is just >> a typed array in our implementation. > > ImageData.data you mean? I wonder if we can still remove CanvasPixelArray. I haven't seen anything that depends on CanvasPixelArray the name, but I wonder if people use the constructor to access the CPA prototype? It could be treated simply as an alias to the appropriate Typed Array constructor i guess, but i'd want to be sure that there's no weirdness with people modifiying both the typed array and cpa prototypes. --Oliver > > > -- > Anne van Kesteren > http://annevankesteren.nl/
Re: [whatwg] ArrayBuffer and the structured clone algorithm
On Tue, 01 Feb 2011 18:36:19 +0100, Boris Zbarsky wrote: On 2/1/11 5:19 AM, Simon Pieters wrote: 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?: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029885.html For what it's worth, in Gecko that's the same thing, since imagedata is just a typed array in our implementation. ImageData.data you mean? I wonder if we can still remove CanvasPixelArray. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] ArrayBuffer and the structured clone algorithm
On 2/1/11 5:19 AM, Simon Pieters wrote: 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?: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029885.html For what it's worth, in Gecko that's the same thing, since imagedata is just a typed array in our implementation. -Boris
Re: [whatwg] ArrayBuffer and the structured clone algorithm
On Tue, 01 Feb 2011 07:47:26 +0100, Kenneth Russell wrote: On Mon, Jan 31, 2011 at 3:10 PM, Ian Hickson 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, +, 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?: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029885.html cheers -- Simon Pieters Opera Software
Re: [whatwg] ArrayBuffer and the structured clone algorithm
On Mon, Jan 31, 2011 at 3:10 PM, Ian Hickson 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, +, 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. -Ken
Re: [whatwg] ArrayBuffer and the structured clone algorithm
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, +, etc.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
