[whatwg] new constructor method for Path2D

[Rik Cabanier]

On Mon, Mar 10, 2014 at 1:33 PM, Justin Novosad <junov at google.com> wrote:

>
>
>
> 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.
>

what I forgot to say is that the path would be stored with the new backend.
For instance, if the path had an internal skia path and it was used on a
Direct2D canvas, the internal skia path would be converted to direct2d and
discarded.
(This will typically only happen once.)


> 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.
>

Yes. If this becomes a performance bottleneck, we could add such an
heuristic.