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

On Mar 7, 2011, at 7:12 PM, Glenn Maynard wrote:

> On Mon, Mar 7, 2011 at 9:07 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 3/7/11 8:55 PM, Glenn Maynard wrote:
> 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.
> 
> But modifying the ImageData is not supposed to modify what the graphics card sees, right?  So you have to make a copy here on putImageData (or on the next write to the image data), right?
> 
> Right, either way you need to make a copy when you send the data back to the canvas.  But, if the surface format of the memory buffer matches a native format of the graphics card, the copy is very fast--probably a DMA, for hardware-accelerated surfaces.  (The exact mechanics of this are hidden behind the drivers, of course, but that's what it looks like in my experience.)  For example, nVidia cards typically are BGRA natively, and if you give them RGBA with OpenGL it needs to be converted before (or as) it's copied, which is much slower.
> 
> (Of course, CanvasPixelData itself always has to *appear* RGBA, but that doesn't mean the backing store needs to actually be RGBA.)
> 
> 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?
> 
> Transparent copy on write requires that each write do a "should I copy?" check, right?
> 
> Yeah.  The question is probably whether that check can be moved out of inner loops.  It couldn't be if function calls are made that might have side-effects to cause a private object to become a COW object (eg. non-pure functions).
> 
> For page-aligned buffers, an implementation could optimize these checks away entirely by marking the buffer read-only, so if a write is made it'll raise an exception that the engine can catch.
> 
> > 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.
> 
> But how is this any different than just throwing away the ArrayBuffer and creating a fresh one after each postMessage?

You can't "throw away" the ArrayBuffer, since the sender still has a reference to it. The proposal we've tossed around would make that ArrayBuffer 0 length, which I suppose is conceptually throwing it away since you can't add a fresh buffer to ArrayBuffer. So maybe it would be better if ArrayBuffer still has the same length but now points at a new buffer of data. This could be done lazily so the buffer need not be allocated until accessed.

-----
~Chris
cmarrin@apple.com