W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2014

Re: [whatwg] new constructor method for Path2D

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 10 Mar 2014 13:22:08 -0700
Message-ID: <CAGN7qDAAded+TF7YNAwKk2rJwWvWaESXctRCsGunhqxhgEn0iw@mail.gmail.com>
To: Justin Novosad <junov@google.com>
Cc: Dirk Schulze <dschulze@adobe.com>, "whatwg@whatwg.org" <whatwg@whatwg.org>, Joe Gregorio <jcgregorio@google.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?
>

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.
Received on Monday, 10 March 2014 20:22:37 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:17 UTC