Re: [whatwg] Canvas in workers

On Mon, Oct 14, 2013 at 1:20 PM, Kenneth Russell <kbr@google.com> wrote:

>   1) Rendering from a worker and displaying on the main thread with no
> extra blits of the rendering results
>   2) Allows one context to render to multiple canvases
>   3) Supports resizing of the drawing buffer
>

The WorkerCanvas proposal should allow #1 and #3.  (It doesn't support #3
for purely offscreen worker canvases, but that'd be easy to add.)  #2 would
be nice with WebGL, where setting up extra contexts can be expensive, and
it may be simpler to do at the Canvas level than by mimicing OpenGL (eg.
shared resources across contexts).

There's been some recent discussion in the WebGL WG on this topic and

concerns were raised from other parties at Mozilla about the
> DrawingBuffer proposal above, including that it isn't possible to
> render from a worker without synchronizing with the main thread.
>

Your proposal does seem to require synchronization with the main thread, at
least with double-buffering.  You postMessage the DrawingBuffer to the main
thread to ask it to be displayed.  The worker can't start drawing the next
frame until it knows that the drawing buffers have been flipped; the buffer
flip happens in the main thread, when transferDrawingBufferToCanvas is
called.

WorkerCanvas performs the flip itself in the worker, when .commit() is
called (and possibly also when the script returns).  Even if the main
thread is busy, the worker should be able to do this immediately.  It does
need to be a thread-safe operation, but it doesn't need to block if the UI
thread is busy.

This proposal doesn't handle synchronizing DOM updates with threaded canvas
updates, but it seems like that inherently requires synchronization...

-- 
Glenn Maynard

Received on Tuesday, 15 October 2013 23:23:49 UTC