W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2013

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

From: Kenneth Russell <kbr@google.com>
Date: Tue, 22 Oct 2013 10:20:57 -0700
Message-ID: <CAMYvS2fXa4CSeGZhZqBWEkxr-C5sdqcrart4joSs48TMw1-auA@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: whatwg <whatwg@whatwg.org>, Robert O'Callahan <robert@ocallahan.org>
On Tue, Oct 22, 2013 at 7:37 AM, Glenn Maynard <glenn@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@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 .

Received on Tuesday, 22 October 2013 17:21:22 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:12 UTC