Re: exposing CANVAS or something like it to Web Workers

On Wed, Jan 2, 2013 at 2:52 PM, Gregg Tavares (社用) <gman@google.com> 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 a real world example see Google's MapsGL
> (http://support.google.com/maps/bin/answer.py?hl=en&answer=1630790)
>
> Apparently MapsGL uses 2 canvases and/or some DOM objects overlayed on top
> of each other.
> Dragging the mouse moves objects in all of those layers and they need to
> move simultaneously
> to have a good UX.
>
> You can imagine issues if a canvas is being rendering to from a worker.
> How would the user
> guarantee that changes from the worker are synchronized with changes to
> the DOM in the
> main thread?
>
> 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?
>

Let me retract this. There is a way under the current API to solve sync
which is to
use drawImage to another canvas in the main thread and have the canvases
being
drawing to by the worker basically as offscreen canvases.

It might not be the ideal solution since a drawImage call is an extra draw
which is
not cheap, especially if it's a large canvas. But, it does mean there's a
solution
for now without adding any extra api.



>
> Random thoughts
>
> *) Leave things the way they are and add another mechanism for syncing?
>
> In other words, by default things are not sync. Through some other API or
> settings the user can opt
> into getting synchronization
>
> *) Look at OpenGL "swap groups" as inspiration for an API?
>
> http://www.opengl.org/registry/specs/NV/wgl_swap_group.txt
> http://www.opengl.org/registry/specs/NV/glx_swap_group.txt
>
> *) Consider an 'oncommit' or 'onswap' event on 'Window'?
>
> The idea being you want to give the main thread a chance to update stuff
> (DOM elements) in response
> to a worker having called 'commit' on a canvas.
>
> Of course not sure how that would work if you have 2 workers each
> rendering to a different canvas.
>
> Note: I haven't thought through these issues at all and I've personally
> not had to deal with them but it
> seems clear from the MapsGL example that a solution will be needed for
> some subset of apps to have
> a good UX. I know for example there's game engine that has API to keep DOM
> elements located
> relative to game objects being rendered in a canvas to make it easy to
> give HTML based stats on
> the game objects as opposed to having to render the stats manually with
> canvas.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Nov 16, 2012 at 8:35 PM, Ian Hickson <ian@hixie.ch> wrote:
>
>> On Fri, 16 Nov 2012, Charles Pritchard wrote:
>> > >
>> > >
>> > >
>> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0199.html
>> >
>> > Seems like we might use requestAnimationFrame in the main thread to
>> > postMessage to the worker as an alternative to using setInterval in
>> > workers for repaints.
>>
>> The idea in due course is to just expose rAF in workers. Please do read
>> the e-mail above, which actually mentions that.
>>
>> --
>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>>
>>
>