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

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@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@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

Received on Tuesday, 22 October 2013 14:37:27 UTC