[whatwg] new constructor method for Path2D

[Justin Novosad]

On Mon, Mar 10, 2014 at 4:22 PM, Rik Cabanier <cabanier at gmail.com> wrote:

>
>
>
> On Mon, Mar 10, 2014 at 11:38 AM, Justin Novosad <junov at google.com> wrote:
>
>>
>>
>>
>> On Mon, Mar 10, 2014 at 2:14 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>>
>>> On Mon, Mar 10, 2014 at 11:07 AM, Joe Gregorio <jcgregorio at 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.