On Mon, Mar 10, 2014 at 4:22 PM, Rik Cabanier <[email protected]> wrote:
> > > > On Mon, Mar 10, 2014 at 11:38 AM, Justin Novosad <[email protected]> wrote: > >> >> >> >> On Mon, Mar 10, 2014 at 2:14 PM, Rik Cabanier <[email protected]> wrote: >> >>> On Mon, Mar 10, 2014 at 11:07 AM, Joe Gregorio <[email protected] >>> >wrote: >>> >>> > >>> >>> > What part is slow, the decoding and re-encoding, or is just always the >>> > encoding step >>> > that is slow? >>> > >>> >>> It's decoding/re-encoding of an already constructed path. >>> >> >> Can't the implementation just perform that work lazily the first time the >> path is rasterized, and retain the cached result for subsequent use of the >> path object? >> > > At usage time, the path could be retargeted to a new backend. 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. > 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.
