[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
too".
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
preserveDrawingBuffer.
> 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,
though.)
--
Glenn Maynard
More information about the whatwg
mailing list