> > 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.