- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 10 Mar 2014 13:03:15 -0700
- To: Justin Novosad <junov@google.com>
- Cc: Dirk Schulze <dschulze@adobe.com>, "whatwg@whatwg.org" <whatwg@whatwg.org>, Joe Gregorio <jcgregorio@google.com>, Rik Cabanier <cabanier@gmail.com>
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? 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. ~TJ
Received on Monday, 10 March 2014 20:04:00 UTC