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

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:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0152.html"including
that it isn't possible to render from a worker without
synchronizing with the main thread."

(My previous comments on this are here:
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg35959.html)


> 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