W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: exposing CANVAS or something like it to Web Workers

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 8 Jan 2013 18:50:01 +0000 (UTC)
To: Gregg Tavares (社用) <gman@google.com>
cc: Charles Pritchard <chuck@jumis.com>, Web Applications Working Group WG <public-webapps@w3.org>
Message-ID: <Pine.LNX.4.64.1301081843080.16292@ps20323.dreamhostps.com>
On Wed, 2 Jan 2013, Gregg Tavares (社~T) wrote:
> Another issue as come up and that is one of being able
> to synchronize updates of a canvas in
> worker with changes in the main page.

For 2D, the intended solution is to just ship the ImageBitamp from the 
worker canvas to the main thread via a MessagePort and then render it on 
the canvas at the appropriate time.

I don't know how you would do it for WebGL.

> Similarly, let's say you have 2 canvases and are rendering to both in a
> worker.  Does
>    context1.commit();
>    context2.commit();
> guarantee you'll see both commits together?

No, unfortunately not. There's no synchronisation between workers and the 
main thread (by design, to prevent any possibility of deadlocks), and 
there's not currently a batching API.

However, if this becomes a common problem (which we can determine by 
seeing if we get bugs complaining about different parts of apps/games 
seeming to slide around or generally be slightly out of sync, or if we see 
a lot of authors shunting multiple ImageBitmap objects across MessagePort 
channels) we can always add an explicit batching API to make this kind of 
thing easy.

Note that in theory, for 2D at least, shunting ImageBitmaps across threads 
can be as efficient as commit().

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 8 January 2013 18:50:23 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:51 UTC