Re: exposing CANVAS or something like it to Web Workers

On 5/14/2012 6:23 PM, Jonas Sicking wrote:
>>>> >>>  This would also require some
>>>> >>>  equivalent to requestAnimationFrame in the worker thread.
>>> >>
>>> >>  Agreed!
>>> >>
>>> >>  / Jonas
>> >
>> >
>> >
>> >  I'm a bit lost-- wouldn't we just postMessage from the document over to the web worker when we want a refresh?
>> >
>> >  I agree that we ought to be transferring pixel data not Canvas contexts; with the possible exception of CSS context.
>> >
>> >  We could just create new canvas instances inside the worker thread. I'd still prefer to clone CanvasPattern as a means of transferring paint over to the worker, though sending pixel data would work too.
>> >
>> >  I heard Picture come up-- it seems like that object might have additional semantics for high resolution alternatives that may need to be considered.
> I was saying that I think we should transfer the context from the main
> thread to the worker thread. The worker thread should then be able to
> use the context to draw directly to the screen without interacting
> with the main thread.
>
> You should generally not need to transfer pixel data. But I think it
> should be possible to grab pixel data on whichever thread is currently
> owning a context. This will implicitly make it possible to transfer
> pixel data if anyone wants to do it.

OK, that's the same concept as I was hoping for with 
document.getCSSCanvasContext.

Mozilla is a bit ahead of webkit, going with  "element(any-element)" -- 
webkit has "-webkit-canvas(css-canvas-id)".

It's a very different approach. I'd still go ahead and just have 
requestAnimationFrame pump events from the main frame.
There are so many things that could block the main frame to where an rAF 
repaint just isn't necessary from the worker-end.

It may also keep some animations continuing. I'm not positive, but 
something like window.prompt may block execution on the main thread, but 
if rAF were running on the worker, its repaints would still happen.
Generally, while the main thread is blocked, repainting on it is not 
going to be that useful; we're shuffling the repaints off so they aren't 
the cause of blocking.

Those are the two sides of it that I see... but it's still a very 
different proposal than the idea of just having non-transferable canvas 
contexts.

...

Boris brought up some good points about possible blocking in 
implementations with loading SVG images in the worker thread via Picture 
(or a chopped down Image). At present, those sound more like 
implementation-issues, not particularly issues in the validity of a spec.
http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0744.html

They do sound a little unfortunate, but I'd sooner trade some possible 
blocking between a Worker and the main thread, than having to carry a 
full SVG parser written in JS in my worker threads.
As an author, I've always had to take precautions for SVG and decide 
whether I want to render or give myself up to the browser implementation.

-Charles

Received on Tuesday, 15 May 2012 01:33:21 UTC