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: Mon, 21 Oct 2013 18:34:08 -0500
Message-ID: <CABirCh_a3M9mW9xvm8W6JMAjJyPkM1bWbebvNfP2DdiAAL2kiQ@mail.gmail.com>
To: Kenneth Russell <kbr@google.com>
Cc: whatwg <whatwg@whatwg.org>, Robert O'Callahan <robert@ocallahan.org>
On Mon, Oct 21, 2013 at 6:08 PM, Kenneth Russell <kbr@google.com> wrote:

> > Using ImageBitmap for this has a lot of issues.  It requires
> synchronizing
> > with scripts in the UI thread.
> This isn't difficult, and amounts to a few additional lines of code in
> the main thread's onmessage handler.

Synchronization with the UI thread isn't bad because it's difficult.
Avoiding synchronization with the main thread has been raised as a
desirable goal:
that it isn't possible to render from a worker without
synchronizing with the main thread."

(My previous comments on this are here:

> The ImageBitmap style proposal has another significant advantage in
> that it allows a single canvas context to present results in multiple
> output regions on the page.

You can do that.  You just create a WorkerCanvas for each canvas you want
to present to, hand them to the worker, then attachToCanvas in the worker
to switch from canvas to canvas.  (That's orthogonal to explicitpresent.)

> This sort of resource exhaustion is certainly possible, but I view
> this downside as smaller than the upside of addressing both of the
> above use cases.

I can only find one thing above that you might be referring to as a use
case (the one I replied to immediately above).  What was the other?

Glenn Maynard
Received on Monday, 21 October 2013 23:34:34 UTC

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