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: Glenn Maynard <glenn@zewt.org>
Date: Sun, 20 Oct 2013 21:46:44 -0500
Message-ID: <CABirCh8+1_hb3U-EzCU_00YBA2niH1rM5SNUkTqhUsaMdeeCxg@mail.gmail.com>
To: Kyle Huey <me@kylehuey.com>
Cc: whatwg <whatwg@whatwg.org>, Kenneth Russell <kbr@google.com>, Robert O'Callahan <robert@ocallahan.org>
(Whoops.  Why did Gmail send that as my work email?  It shouldn't have made
it through to the list, since it's not subscribed...)


On Sun, Oct 20, 2013 at 9:26 PM, Kyle Huey <me@kylehuey.com> wrote:

> On Sun, Oct 20, 2013 at 11:33 PM, Glenn Maynard <glenn@bluegoji.com>wrote:
>
>> It must not be possible for the UI thread to detect whether present() did
>> anything--if there's no frame in the ready buffer, nothing changes and the
>> UI thread can't detect this.  Similarly, it must not be possible for the
>> rendering thread to detect if the ready frame has been presented.  These
>> rules are to prevent exposing asynchronous behavior.
>>
>
> Well you can readback from <canvas>es, so how is that going to work?
>

However it works today, since CanvasProxy needs the same thing.  If a
CanvasProxy/WorkerCanvas exists for a canvas, you should have to use a
toBlob method on that, and calls to that (and earlier calls in progress) on
the Canvas itself should fail.  (If CanvasProxy isn't doing that it seems
like a bug.)
Received on Monday, 21 October 2013 02:47:09 UTC

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