Re: [whatwg] ArrayBuffer and ByteArray questions
On Sep 8, 2010, at 12:13 AM, Anne van Kesteren wrote: On Wed, 08 Sep 2010 01:09:13 +0200, Jian Li jia...@chromium.org wrote: Several specs, like File API and WebGL, use ArrayBuffer, while other spec, like XMLHttpRequest Level 2, use ByteArray. Should we change to use the same name all across our specs? Since we define ArrayBuffer in the Typed Arrays spec ( https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html), should we favor ArrayBuffer? In addition, can we consider adding ArrayBuffer support to BlobBuilder, FormData, and XMLHttpRequest.send()? So TC39 is going to leave this thing alone? I.e. are we sure ArrayBuffer is the way of the future? ArrayBuffer certainly has momentum behind it. It started as a part of the WebGL spec as a way of passing buffers of data of various types (sometimes heterogeneous types) to the WebGL engine. Since then, it has found uses in the Web Audio proposal, the File API and there has been talk in using it as a way to pass data to Web Workers. We have discussed using it in XHR as well, and I think that would be a great idea. From a WebGL standpoint, it is the one missing piece to make it possible to easily get data of any type from a URL into the WebGL engine. But it would have uses in many other places as well. For reference, here is the latest proposal: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html - ~Chris cmar...@apple.com
Re: [whatwg] ArrayBuffer and ByteArray questions
On Wed, 08 Sep 2010 17:22:44 +0200, Chris Marrin cmar...@apple.com wrote: On Sep 8, 2010, at 12:13 AM, Anne van Kesteren wrote: On Wed, 08 Sep 2010 01:09:13 +0200, Jian Li jia...@chromium.org wrote: Several specs, like File API and WebGL, use ArrayBuffer, while other spec, like XMLHttpRequest Level 2, use ByteArray. Should we change to use the same name all across our specs? Since we define ArrayBuffer in the Typed Arrays spec ( https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html), should we favor ArrayBuffer? In addition, can we consider adding ArrayBuffer support to BlobBuilder, FormData, and XMLHttpRequest.send()? So TC39 is going to leave this thing alone? I.e. are we sure ArrayBuffer is the way of the future? ArrayBuffer certainly has momentum behind it. It started as a part of the WebGL spec as a way of passing buffers of data of various types (sometimes heterogeneous types) to the WebGL engine. Since then, it has found uses in the Web Audio proposal, the File API and there has been talk in using it as a way to pass data to Web Workers. Do you mean WebSockets? We have discussed using it in XHR as well, and I think that would be a great idea. From a WebGL standpoint, it is the one missing piece to make it possible to easily get data of any type from a URL into the WebGL engine. But it would have uses in many other places as well. For reference, here is the latest proposal: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html - ~Chris cmar...@apple.com -- Simon Pieters Opera Software
Re: [whatwg] ArrayBuffer and ByteArray questions
On Sep 8, 2010, at 9:44 AM, Simon Pieters wrote: On Wed, 08 Sep 2010 17:22:44 +0200, Chris Marrin cmar...@apple.com wrote: On Sep 8, 2010, at 12:13 AM, Anne van Kesteren wrote: On Wed, 08 Sep 2010 01:09:13 +0200, Jian Li jia...@chromium.org wrote: Several specs, like File API and WebGL, use ArrayBuffer, while other spec, like XMLHttpRequest Level 2, use ByteArray. Should we change to use the same name all across our specs? Since we define ArrayBuffer in the Typed Arrays spec ( https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html), should we favor ArrayBuffer? In addition, can we consider adding ArrayBuffer support to BlobBuilder, FormData, and XMLHttpRequest.send()? So TC39 is going to leave this thing alone? I.e. are we sure ArrayBuffer is the way of the future? ArrayBuffer certainly has momentum behind it. It started as a part of the WebGL spec as a way of passing buffers of data of various types (sometimes heterogeneous types) to the WebGL engine. Since then, it has found uses in the Web Audio proposal, the File API and there has been talk in using it as a way to pass data to Web Workers. Do you mean WebSockets? Web Sockets is certainly another candidate, but I meant Web Workers. There have been informal discussions on using ArrayBuffers as a way to safely share binary data between threads. I don't believe anything has been formalized here. - ~Chris cmar...@apple.com
Re: [whatwg] ArrayBuffer and ByteArray questions
On Wed, 08 Sep 2010 20:13:19 +0200, Chris Marrin cmar...@apple.com wrote: ArrayBuffer certainly has momentum behind it. It started as a part of the WebGL spec as a way of passing buffers of data of various types (sometimes heterogeneous types) to the WebGL engine. Since then, it has found uses in the Web Audio proposal, the File API and there has been talk in using it as a way to pass data to Web Workers. Do you mean WebSockets? Web Sockets is certainly another candidate, but I meant Web Workers. There have been informal discussions on using ArrayBuffers as a way to safely share binary data between threads. I don't believe anything has been formalized here. Oh, as in posting to a worker with postMessage? Yeah that could be useful. A side-effect of speccing this would be that other stuff that use the structured clone algorithm would also support ArrayBuffer, e.g. localStorage. -- Simon Pieters Opera Software
Re: [whatwg] ArrayBuffer and ByteArray questions
On Sep 8, 2010, at 11:13 AM, Chris Marrin wrote: Web Sockets is certainly another candidate, but I meant Web Workers. There have been informal discussions on using ArrayBuffers as a way to safely share binary data between threads. I don't believe anything has been formalized here. You can't share data between workers. There is no (and there cannot be) any shared state between multiple threads of JS execution.
Re: [whatwg] ArrayBuffer and ByteArray questions
On Wed, Sep 8, 2010 at 11:21 AM, Oliver Hunt oli...@apple.com wrote: On Sep 8, 2010, at 11:13 AM, Chris Marrin wrote: Web Sockets is certainly another candidate, but I meant Web Workers. There have been informal discussions on using ArrayBuffers as a way to safely share binary data between threads. I don't believe anything has been formalized here. You can't share data between workers. There is no (and there cannot be) any shared state between multiple threads of JS execution. Let's say efficiently send rather than share. The current thinking has been around a way to post one ArrayBuffer to a worker which would close that ArrayBuffer and all views on the main thread. The way to get the same backing store from the worker back to the main thread would be to post the ArrayBuffer from the worker to the main thread, at which point the ArrayBuffer and all views on the worker would be closed. This ping-ponging would allow efficient implementation of producer/consumer queues without allocating new backing store each time the worker wants to produce something for the main thread. This would require some small API additions to the typed array spec, and a prototype so we can convince ourselves of its effectiveness. -Ken
Re: [whatwg] ArrayBuffer and ByteArray questions
On Sep 8, 2010, at 11:21 AM, Oliver Hunt wrote: On Sep 8, 2010, at 11:13 AM, Chris Marrin wrote: Web Sockets is certainly another candidate, but I meant Web Workers. There have been informal discussions on using ArrayBuffers as a way to safely share binary data between threads. I don't believe anything has been formalized here. You can't share data between workers. There is no (and there cannot be) any shared state between multiple threads of JS execution. Right. I didn't mean literal sharing. But you can imagine some copy-on-write semantics which would make it more efficient to pass data this way. - ~Chris cmar...@apple.com
Re: [whatwg] ArrayBuffer and ByteArray questions
On Thu, Sep 9, 2010 at 4:37 AM, Chris Marrin cmar...@apple.com wrote: On Sep 8, 2010, at 11:21 AM, Oliver Hunt wrote: On Sep 8, 2010, at 11:13 AM, Chris Marrin wrote: Web Sockets is certainly another candidate, but I meant Web Workers. There have been informal discussions on using ArrayBuffers as a way to safely share binary data between threads. I don't believe anything has been formalized here. You can't share data between workers. There is no (and there cannot be) any shared state between multiple threads of JS execution. Right. I didn't mean literal sharing. But you can imagine some copy-on-write semantics which would make it more efficient to pass data this way. Is this then similar to posting ImageData with Web Workers? ( http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#imagedata) . I know that these can already be put into a postMessage and they are effectively arrays. Cheers, Silvia.
Re: [whatwg] ArrayBuffer and ByteArray questions
On Wed, Sep 8, 2010 at 5:04 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Thu, Sep 9, 2010 at 4:37 AM, Chris Marrin cmar...@apple.com wrote: On Sep 8, 2010, at 11:21 AM, Oliver Hunt wrote: On Sep 8, 2010, at 11:13 AM, Chris Marrin wrote: Web Sockets is certainly another candidate, but I meant Web Workers. There have been informal discussions on using ArrayBuffers as a way to safely share binary data between threads. I don't believe anything has been formalized here. You can't share data between workers. There is no (and there cannot be) any shared state between multiple threads of JS execution. Right. I didn't mean literal sharing. But you can imagine some copy-on-write semantics which would make it more efficient to pass data this way. Is this then similar to posting ImageData with Web Workers? (http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#imagedata) . I know that these can already be put into a postMessage and they are effectively arrays. It's similar, but we want to define different semantics to achieve higher performance. Copy-on-write does not work because in a producer/consumer scenario the producer will always overwrite the same buffer passed to the consumer, leading to a copy each time. We want to make the source ArrayBuffer, and any ArrayBufferViews, zero length upon posting them to a worker or back to the main thread. By ping-ponging the same ArrayBuffer back and forth you can avoid allocating new backing store each iteration. -Ken
