On 5/14/2012 6:14 PM, Gregg Tavares (勤) wrote:
On Mon, May 14, 2012 at 6:07 PM, Boris Zbarsky <[email protected]
<mailto:[email protected]>> 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.
