Re: ArrayBuffer and ByteArray questions
On Wed, Sep 15, 2010 at 6:53 PM, Arun Ranganathan a...@mozilla.com wrote: On 9/7/10 10:08 PM, Darin Fisher wrote: On Tue, Sep 7, 2010 at 5:23 PM, Kenneth Russell k...@google.com wrote: On Tue, Sep 7, 2010 at 4:19 PM, Nathan nat...@webr3.org wrote: Jian Li wrote: Hi, 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()? which reminds me, I meant to ask if the aforementioned TypedArray spec should be brought in to webapps / w3c land? seems to complement the other base types used in webidl etc rather well + my gut reaction was why isn't this standardized within w3c? There's no particular reason why the Typed Array spec is being standardized in the Khronos group, aside from the fact that these array-like types originated in the WebGL spec and have evolved to meet use cases specified by WebGL. We have been hoping that they would have uses outside of WebGL, and some discussions have occurred with working groups such as TC39 to see how they might be better specified and standardized. We'd be open to hosting the spec development elsewhere. Vlad mentioned to me off-list that Mozilla has implemented an experimental mozResponseArrayBuffer on XHR objects, and will likely do the same on the File API to add a readAsArrayBuffer alongside readAsBinaryString etc. -Ken It sounds like ArrayBuffer is the name that is gaining traction (to circle back to Jian's original question about naming). In fact, readAsArrayBuffer / ArrayBuffer is used with FileReader, and will be the names going forward. ArrayBuffer is gaining traction as the used name :) -- A* I've added BlobBuilder.append(ArrayBuffer). Eric
Re: ArrayBuffer and ByteArray questions
On 9/7/10 10:08 PM, Darin Fisher wrote: On Tue, Sep 7, 2010 at 5:23 PM, Kenneth Russell k...@google.com mailto:k...@google.com wrote: On Tue, Sep 7, 2010 at 4:19 PM, Nathan nat...@webr3.org mailto:nat...@webr3.org wrote: Jian Li wrote: Hi, 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()? which reminds me, I meant to ask if the aforementioned TypedArray spec should be brought in to webapps / w3c land? seems to complement the other base types used in webidl etc rather well + my gut reaction was why isn't this standardized within w3c? There's no particular reason why the Typed Array spec is being standardized in the Khronos group, aside from the fact that these array-like types originated in the WebGL spec and have evolved to meet use cases specified by WebGL. We have been hoping that they would have uses outside of WebGL, and some discussions have occurred with working groups such as TC39 to see how they might be better specified and standardized. We'd be open to hosting the spec development elsewhere. Vlad mentioned to me off-list that Mozilla has implemented an experimental mozResponseArrayBuffer on XHR objects, and will likely do the same on the File API to add a readAsArrayBuffer alongside readAsBinaryString etc. -Ken It sounds like ArrayBuffer is the name that is gaining traction (to circle back to Jian's original question about naming). In fact, readAsArrayBuffer / ArrayBuffer is used with FileReader, and will be the names going forward. ArrayBuffer is gaining traction as the used name :) -- A* -Darin
Re: ArrayBuffer and ByteArray questions
Yes, we only need to add it to BlobBuilder so that it can be applied to both FileReader, XHR.send and any other place that take the blob. On Wed, Sep 8, 2010 at 10:57 AM, Eric Uhrhane er...@google.com wrote: On Tue, Sep 7, 2010 at 4:09 PM, Jian Li jia...@chromium.org wrote: Hi, 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()? It seems like an obvious addition for BlobBuilder or XHR.send, but do we need it in both, or is one sufficient? Thanks, Jian
Re: ArrayBuffer and ByteArray questions
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? -- Anne van Kesteren http://annevankesteren.nl/
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: ArrayBuffer and ByteArray questions
On Tue, Sep 7, 2010 at 4:09 PM, Jian Li jia...@chromium.org wrote: Hi, 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()? It seems like an obvious addition for BlobBuilder or XHR.send, but do we need it in both, or is one sufficient? Thanks, Jian
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
ArrayBuffer and ByteArray questions
Hi, 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()? Thanks, Jian
Re: ArrayBuffer and ByteArray questions
Jian Li wrote: Hi, 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()? which reminds me, I meant to ask if the aforementioned TypedArray spec should be brought in to webapps / w3c land? seems to complement the other base types used in webidl etc rather well + my gut reaction was why isn't this standardized within w3c? Best, Nathan
Re: ArrayBuffer and ByteArray questions
On Tue, Sep 7, 2010 at 4:19 PM, Nathan nat...@webr3.org wrote: Jian Li wrote: Hi, 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()? which reminds me, I meant to ask if the aforementioned TypedArray spec should be brought in to webapps / w3c land? seems to complement the other base types used in webidl etc rather well + my gut reaction was why isn't this standardized within w3c? There's no particular reason why the Typed Array spec is being standardized in the Khronos group, aside from the fact that these array-like types originated in the WebGL spec and have evolved to meet use cases specified by WebGL. We have been hoping that they would have uses outside of WebGL, and some discussions have occurred with working groups such as TC39 to see how they might be better specified and standardized. We'd be open to hosting the spec development elsewhere. Vlad mentioned to me off-list that Mozilla has implemented an experimental mozResponseArrayBuffer on XHR objects, and will likely do the same on the File API to add a readAsArrayBuffer alongside readAsBinaryString etc. -Ken
Re: ArrayBuffer and ByteArray questions
On Tue, Sep 7, 2010 at 5:23 PM, Kenneth Russell k...@google.com wrote: On Tue, Sep 7, 2010 at 4:19 PM, Nathan nat...@webr3.org wrote: Jian Li wrote: Hi, 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()? which reminds me, I meant to ask if the aforementioned TypedArray spec should be brought in to webapps / w3c land? seems to complement the other base types used in webidl etc rather well + my gut reaction was why isn't this standardized within w3c? There's no particular reason why the Typed Array spec is being standardized in the Khronos group, aside from the fact that these array-like types originated in the WebGL spec and have evolved to meet use cases specified by WebGL. We have been hoping that they would have uses outside of WebGL, and some discussions have occurred with working groups such as TC39 to see how they might be better specified and standardized. We'd be open to hosting the spec development elsewhere. Vlad mentioned to me off-list that Mozilla has implemented an experimental mozResponseArrayBuffer on XHR objects, and will likely do the same on the File API to add a readAsArrayBuffer alongside readAsBinaryString etc. -Ken It sounds like ArrayBuffer is the name that is gaining traction (to circle back to Jian's original question about naming). -Darin
