[whatwg] Counterproposal for canvas in workers

[Glenn Maynard]

On Thu, Oct 17, 2013 at 8:22 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> That's not really a use-case. What would you actually be trying to do?
> IIUC Ken agreed that his use-cases that appeared to require a single
> context rendering to multiple canvases would be addressed just as easily
> (or better) by using multiple image elements, a single canvas, and doing
> "image.srcObject = canvas.transferToImageBuffer()".
>

I wasn't arguing a use case, I was agreeing with a feature.  I think the
use cases for rendering to multiple DOM elements (canvases or otherwise)
using WebGL are already well-established (less so for 2d canvas).

"transferToImageBuffer" looks like it would create a new ImageBuffer for
each frame, so you'd need to add a close() method to make sure they don't
accumulate due to GC lag, and it seems like turning this into a fast buffer
swap under the hood would be harder.  If you just point the context at the
final canvas in the first place, it can render directly into that canvas's
backbuffer, so the buffer flipping mechanics are identical to when it isn't
being used at all.

Also, with the "transferToImageBuffer" approach, if you want to render from
a worker into multiple canvases in the UI thread, you have to post those
ImageBuffers over to the main thread each frame, which has the same
(potential) synchronization issues as the transferDrawingBufferToCanvas
proposal.  With attachToCanvas, it's just like WorkerCanvas: the buffer
flipping can happen entirely within the worker.

-- 
Glenn Maynard