[whatwg] new constructor method for Path2D

[Rik Cabanier]

On Mon, Mar 10, 2014 at 11:07 AM, Joe Gregorio <jcgregorio at google.com>wrote:

>
>
>
> On Mon, Mar 10, 2014 at 2:02 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>>
>>
>> What are you not sure about?
>>
>> The current Path2D interface might be unacceptably slow under certain
>> circumstances and there's currently no way for authors to work around
>> this.
>> There has to be a hint. If not, I don't see a way that firefox will ship
>> this.
>>
>
> 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.


> I thought the speed of Path2D came from the reuse, that is, that the build
> cost wasn't
> a big concern because the speed came from reusing that same object over
> and over
> at up to 60fps?
>

Yes. The concern is that the re-encoding will happen every time you use the
path.

We could code it in such a way that the path is retargeted when it's used.
It's a bit strange since fill and stroke are not supposed to "change" the
path.