- From: Justin Novosad <junov@google.com>
- Date: Mon, 10 Mar 2014 16:33:37 -0400
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: Dirk Schulze <dschulze@adobe.com>, "whatwg@whatwg.org" <whatwg@whatwg.org>, Joe Gregorio <jcgregorio@google.com>
On Mon, Mar 10, 2014 at 4:22 PM, Rik Cabanier <cabanier@gmail.com> wrote: > > > > On Mon, Mar 10, 2014 at 11:38 AM, Justin Novosad <junov@google.com> wrote: > >> >> >> >> On Mon, Mar 10, 2014 at 2:14 PM, Rik Cabanier <cabanier@gmail.com> wrote: >> >>> On Mon, Mar 10, 2014 at 11:07 AM, Joe Gregorio <jcgregorio@google.com >>> >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.
Received on Monday, 10 March 2014 20:34:01 UTC