Re: Using ArrayBuffer as payload for binary data to/from Web Workers

On Mon, Mar 7, 2011 at 5:55 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Mon, Mar 7, 2011 at 8:04 PM, Chris Marrin <cmarrin@apple.com> wrote:
>>
>> > Probably not the only one, but check the "WebWorkers and images" thread
>> > on whatwg.
>>
>> Yeah, I thought about that case. The extra complication there is that
>> images are rendering resources, which muddies the issues some. If the 2D
>> Canvas API were able to use ArrayBuffer data as an image source like WebGL
>> can, then we could kill 2 birds with one stone. Pass the ArrayBuffer to the
>> worker and have it generate some image data, then pass it back and render it
>> to a canvas. You could even split the array buffer into tiles and have
>> multiple workers operate on the tiles.
>
> I'd expect CanvasPixelArray to allow optimizations that ArrayBuffer doesn't,
> since the implementation can use the native surface format, translating to
> RGBA for the script transparently.  This can matter for streaming textures
> to OpenGL/D3D, too; creating BGRA textures on nVidia hardware is typically
> much faster than RGBA ones.
>
> I don't recall if this has been brought up: are there cases where explicit
> zero-copy messaging is better than transparent copy-on-write?

Yes. Copy on write does not efficiently handle the case where large
amounts of data are continually produced by workers and posted to the
main thread for display. Each time the worker posts a block of data to
the main thread, the next time it attempts to update its version of
the block for the next iteration, a copy will need to be made so the
main thread's version appears immutable.

Bi-directional, zero-copy messaging is needed to preserve ECMAScript's
shared-nothing semantic while avoiding a continuous stream of memory
allocation for producer/consumer queues between workers and the main
thread. The Vertex Buffer Object demo at
http://khronos.org/webgl/wiki/Demo_Repository provides an example
where multiple workers should be able to produce independent portions
of the mesh for rendering by the main thread, and where a nearly
linear speedup is possible.

-Ken

Received on Tuesday, 8 March 2011 02:16:59 UTC