Re: exposing CANVAS or something like it to Web Workers

On 5/14/2012 6:14 PM, Gregg Tavares (勤) wrote:
>
>
> On Mon, May 14, 2012 at 6:07 PM, Boris Zbarsky <bzbarsky@mit.edu 
> <mailto:bzbarsky@mit.edu>> wrote:
>
>     On 5/14/12 8:55 PM, Gregg Tavares (勤) wrote:
>
>            1)  Various canvas 2d context methods depend on the styles
>         of the
>            canvas to define how they actually behave.  Clearly this
>         would need
>            some sort of changes for Workers anyway; the question is
>         what those
>            changes would need to be.
>
>         Which methods are these?
>
>
>     Anything involving setting color (e.g. the strokeStyle setter, the
>     fillStyle setter), due to "currentColor".  Anything involving text
>     because font styles come from the element or document.
>
>
> Good to know.
>
> That doesn't sound like a showstopper though. If a 
> canvas/CanvasSurface is available in workers the simplest solution 
> would just be that "currentColor" defaults to something "black?" or 
> nothing "". Pick one.

Font is still a little tricky from loading fonts via CSS. Font is tricky 
anyway, though, so it wouldn't be that much of a step backward.

Would we assume that if a font is available from the parent context it's 
going to be available to the worker?

currentColor would just default to black, as we're not talking about a 
color inherited from the DOM.


>     Those are the ones that come to mind offhand, but I haven't looked
>     at the various recent additions to the 2d context closely.
>

The recent additions are more proposals than additions. They're 
proposals from Tab and Ian and not yet implemented.

They revolve around a Path object, which we've not yet discussed.
Otherwise, they include lightweight nodes and DOM fallback content, 
which isn't relevant to workers.

My thinking is the same as yours: fillStyle/strokeStyle and font are the 
ones that come to mind.
Pattern and Gradient are items that could conceivably be cloned and/or 
shared.
They can both be as efficient as sending Blob via postMessage.

I think Gregg was just settling on not-sending Canvas over postMessage 
but rather creating the instance inside of each Worker.