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

[Kenneth Russell]

On Tue, Oct 22, 2013 at 7:37 AM, Glenn Maynard <glenn at zewt.org> wrote:
> I just noticed that Canvas already has a Canvas.setContext() method

That's there in support of CanvasProxy, which is a flawed API and
which this entire discussion is aiming to rectify.

> , 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".

Also, adding a present() method to Canvas.

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

At a high level I prefer the form of the WorkerCanvas API, including
transferToImageBitmap and the ability to transfer an ImageBitmap into
an HTMLImageElement for viewing, and removing the CanvasProxy concept
and associated APIs. I'd like to focus my own efforts in writing a
full draft for WorkerCanvas under
http://wiki.whatwg.org/wiki/Category:Proposals .

-Ken