[whatwg] Synchronizing Canvas updates in a worker to DOM changes in the UI thread

Glenn Maynard glenn at zewt.org
Tue Oct 22 07:37:01 PDT 2013

I just noticed that Canvas already has a Canvas.setContext() method, which
seems to do exactly what I'm proposing, even down to clearing the
backbuffer on attach.  The only difference is that it lives on Canvas
instead of the context--the only reason I put it there in my proposal was
because this only seemed useful for WebGL.  Given that, I think this
proposal can be simplified down to just: "put setContext on WorkerCanvas

On Mon, Oct 21, 2013 at 9:03 PM, Kenneth Russell <kbr at google.com> wrote:

> There are some unexpected consequences of the attachToCanvas API
> style. For example, what if two contexts use attachToCanvas to target
> the same canvas?

I left out these details in my initial post in order to see what people
thought at a high level before delving into details.  Attaching when
already attached would replace the old attachment.  It's not possible for
two workers to attach to the same canvas, since only a single WorkerCanvas
can exist for any given canvas; and the original Canvas can't be attached
to if a WorkerCanvas was created (eg. it's in the "proxied" mode).

> What if one of those contexts is 2D and the other is
> WebGL? Currently it's illegal to try to fetch two different context
> types for a single Canvas. The current CanvasProxy spec contains
> several complex rules for these cases, and they're not easy to
> understand.

This is handled by setContext: attaching a context detaches any
previously-attached context.

> Will it be guaranteed that if you have a WebGL context, attachToCanvas
> to canvas1, do some rendering, and then attachToCanvas to canvas2,
> that the only remaining buffer in canvas1 is its color buffer? No
> depth buffers, multisample buffers, etc. will have to remain for some
> reason?

If you reattach to canvas1 in the future, the buffers are cleared, which
means you can discard or reuse those buffers as soon as you attach to a
different canvas.

> How would WebGL's preserveDrawingBuffer attribute, which is a property
> of the context, interact with directing its output to multiple
> canvases?

Since attaching the canvas clears it, that would override

> Fundamentally I think the behavior is easier to spec, and the
> implementation is easier to make correct, if the ultimate destination
> is an image rather than a canvas, and the color buffer is transferred
> out of the WorkerCanvas in an explicit step.

Whether that's true or not, making things easy for the user takes priority
over making things easy for spec writers and implementation.

On Tue, Oct 22, 2013 at 2:48 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> This code actually does something potentially useful which can't easily be
> done with attachToCanvas: generating a series of images as fast as possible
> which will be processed on another thread in some way other than just
> rendering them on the screen. (E.g., be encoded into an animated image or
> video file.)

(This is a proposal for attachToCanvas--now setContext--not against
transferToImageBitmap, if there are use cases that transferToImageBitmap
solves best in its own right.  It seems like toBlob already handles this,

Glenn Maynard

More information about the whatwg mailing list