[whatwg] new constructor method for Path2D

[Dirk Schulze]

On Mar 10, 2014, at 7:02 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> On Sun, Mar 9, 2014 at 10:52 PM, Dirk Schulze <dschulze at adobe.com> wrote:
> 
>> 
>> 
>>> On Mar 10, 2014, at 3:44 AM, "Rik Cabanier" <cabanier at gmail.com> wrote:
>>> 
>>>> On Wed, Mar 5, 2014 at 1:46 PM, Rik Cabanier <cabanier at gmail.com>
>> wrote:
>>>> 
>>>> While implementing the Path2D object in mozilla, we ran into a
>> performance
>>>> issue.
>>>> 
>>>> The mozilla implementation uses different "backends" for the canvas 2D
>>>> context.
>>>> Even within the same document, different canvas objects can be on top of
>>>> different graphics libraries. For best performance, the Path2D object
>>>> should use the same graphics interface as the canvas context you're
>>>> applying it to. If this is not the case, the path segments have to be
>>>> walked and converted which is a costly operation.
>>>> 
>>>> To work around this, we could add a couple of constructor methods to the
>>>> 2D context:
>>>> 
>>>> Path2D createPath();
>>>> 
>>>> Creates a new empty Path object.
>>>> 
>>>> Path2D createPath(path);
>>>> 
>>>> Creates a new Path object that is a copy of the argument.
>>>> 
>>>> Path2D createPath(d);
>>>> 
>>>> Creates a new path with the path described by the argument, interpreted
>> as
>>>> SVG path data. [SVG]
>>>> 
>>>> This way, we can guarantee that they use the same underlying technology
>>>> and performance won't be impacted.
>>>> You could still pass these objects to other canvas contexts but
>>>> performance might be impacted.
>>> 
>>> I was thinking about this a bit more and an alternate solution would be
>> to
>>> pass an optional 2D context to the Path2D constructors.
>>> A UA could ignore that context, or it could see it as a hint that the
>> path
>>> is going to be used with that context.
>>> 
>>> Thoughts?
>> 
>> Slightly better. Still not sure.
>> 
> 
> 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.

Since no other implementation stood up so far it seems to be a FF only hack at the moment.

The question is how common s it to have multiple contexts of different type within the same document? How often does it happen that you use the same Path2d object in multiple contexts? We need data for that first.

Even switching the context during run-time (as you suggested is happening in Firefox) would not help in your proposal. You would still encode and decode the path again.

Actually, with the right abstraction it is just the creation of the path object which shouldn’t be very slow at all. Especially since you create it once and reuse it over and over again.

Having an optional value for the constructor is not as bad as binding the Path2d creation to a specific context. I still don’t see the need to do this at the moment.

Beside that, the optional argument can be done later if it really turns out to be a problem that can not worked around in any other way. Therefore, I would like to see efforts in Gecko to speed the specified version up first and revisit the proposal later.

Greetings,
Dirk