[whatwg] Canvas and Paths

[Rik Cabanier]

>
> On Mon, 10 Mar 2014, Tab Atkins Jr. wrote:
> >
> > This is also my question.  Given that generating a path for a particular
> > context isn't a magic bullet *anyway* (because the details of the
> > context can change), I don't understand why caching isn't the answer.
>
> On Mon, 10 Mar 2014, Rik Cabanier wrote:
> >
> > At usage time, the path could be retargeted to a new backend.
>
> If the backend changes, knowing the backend at creation time doesn't help.
>
> If it doesn't, then the cost seems to be the same either way.
>
>
> > I don't think that should be done as a cached copy since that would
> > require too many resources. I will see if this is an acceptable solution
> > for mozilla.
>
> How many resources could a path possibly take?
>
>
> On Mon, 10 Mar 2014, Justin Novosad wrote:
> >
> > Isn't caching ideal for that situation? In the case of re-targeting, you
> > can either replace the cached encoding, or append the new encoding to a
> > collection of cached encodings.  Both of those options seem more
> > effective than to stick to an encoding type that was baked-in at
> > construction time. It may also be great to have a heuristic to chose
> > whether to discard the previously cached re-encoding. Something like: if
> > we are re-encoding because the destination backing type changed due to a
> > resize, then discard previous encodings; if re-encoding because the path
> > is drawn to multiple canvases, then retain multiple cached encodings.
>
> That makes sense to me.
>

FYI
The Firefox people agreed to a solution that retargets the path if its
backend doesn't match with the canvas context backend.
There's no need to change to current API.