Re: exposing CANVAS or something like it to Web Workers

Chrome extensions have a background.html capability with a full dom; I've used those to prototype the concept. I've also used webkit's CSS fill (-webkit-canvas) in the mix.

A good deal of experimentation can be done there, prior to hacking up C++.



On Feb 20, 2013, at 11:43 AM, Kenneth Russell <kbr@google.com> wrote:

> On Fri, Feb 8, 2013 at 9:14 AM, Travis Leithead
> <travis.leithead@microsoft.com> wrote:
>>>> What would be the advantage? If you wanted to keep dom elements in sync
>>>> with the canvas you'd still have to post something from the worker back to
>>>> the main thread so the main thread would know to pop.
>> 
>> 
>> 
>> Well, it's not a fleshed out proposal by any stretch, but you could imagine
>> that an event could be used to signal that new frames were ready from the
>> producer—then the main thread would know to pop.
> 
> It sounds like this approach would require a bunch of new concepts --
> a remote worker context, events signalled through it, etc. It would
> still be necessary to postMessage from the main thread back to the
> worker for flow control. Flow control is definitely necessary -- the
> producer can't just produce frames without any feedback about when
> they're actually consumed. We've had problems in Chrome's graphics
> pipeline in the past where lack of flow control led to slow and
> inconsistent frame rates.
> 
> I'm excited about Gregg's proposal because it solves a lot of use
> cases that aren't currently addressed by CanvasProxy, using a couple
> of simple primitives that build upon others already in the platform
> (cross-document messaging and Transferables).
> 
> How can we move forward so that user agents can experimentally
> implement these APIs? Ideally we'd prototype and experiment with them
> in some medium-sized applications before finalizing any specs in this
> area.
> 
> Thanks,
> 
> -Ken
> 
> 
>> From: Gregg Tavares [mailto:gman@google.com]
>> Sent: Friday, February 8, 2013 3:14 AM
>> To: Travis Leithead
>> Cc: Ian Hickson; Charles Pritchard; Web Applications Working Group WG
>> 
>> 
>> Subject: Re: exposing CANVAS or something like it to Web Workers
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Thu, Feb 7, 2013 at 10:46 PM, Travis Leithead
>> <travis.leithead@microsoft.com> wrote:
>> 
>> Having thought about this before, I wonder why we don’t use a
>> producer/consumer model rather than a transfer of canvas ownership model?
>> 
>> 
>> 
>> A completely orthogonal idea (just my rough 2c after reading Gregg’s
>> proposal), is to have an internal frame buffer accessible via a WorkerCanvas
>> API which supports some set of canvas 2d/3d APIs as appropriate, and can
>> “push” a completed frame onto a stack in the internal frame buffer. Thus the
>> worker can produce frames as fast as desired.
>> 
>> 
>> 
>> On the document side, canvas gets a 3rd kind of context—a
>> WorkerRemoteContext, which just offers the “pop” API to pop a frame from the
>> internal frame buffer into the canvas.
>> 
>> 
>> 
>> Then you just add some basic signaling events on both ends of the frame
>> buffer and you’re good (as far as synchronizing the worker with the
>> document). The producer (in the worker) is free to produce multiple frames
>> in advance (if desired), while the consumer is able to pop frames when
>> available. You could even have the framebuffer depth configurable.
>> 
>> 
>> 
>> What would be the advantage? If you wanted to keep dom elements in sync with
>> the canvas you'd still have to post something from the worker back to the
>> main thread so the main thread would know to pop.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> From: Gregg Tavares [mailto:gman@google.com]
>> Sent: Thursday, February 7, 2013 2:25 PM
>> To: Ian Hickson
>> Cc: Charles Pritchard; Web Applications Working Group WG
>> Subject: Re: exposing CANVAS or something like it to Web Workers
>> 
>> 
>> 
>> I put up a new proposal for canvas in workers
>> 
>> 
>> 
>> http://wiki.whatwg.org/wiki/CanvasInWorkers
>> 
>> 
>> 
>> Please take a look.
>> 
>> 
>> 
>> This proposal comes from offline discussions with representatives from the
>> various browsers as well as input from the Google Maps team. I can post a
>> summary here if you'd like but it might be easier to read the wiki
>> 
>> 
>> 
>> Looking forward to feedback.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Tue, Jan 8, 2013 at 10:50 AM, Ian Hickson <ian@hixie.ch> wrote:
>> 
>> 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 Wednesday, 20 February 2013 19:57:37 UTC