[whatwg] CanvasRenderingContext2D with addPath, currentPath

[Rik Cabanier]

The latest Safari is shipping currentPath and Blink has implemented it
behind a runtime flag.
Could we put this in the specification?

the proposal is for a new attribute on the 2d canvas rendering context:

attribute Path currentPath;


This attribute would give you a non-live/copy of the current path in device
space.
You can also set a path, again in device space (meaning that the current
CTM would not be applied).

For instance:

var ctx = ...getContext("2d");

ctx.scale(2, 2);

ctx.moveTo(10, 10);

ctx.lineTo(100, 10);

var p = ctx.currentPath;


Path p would contain a line from (20, 20) to (200, 20)

Likewise:

var p = new Path();

p.moveTo(10, 10);
p.lineTo(100, 10);
ctx.scale(2, 2);

ctx.currentPath = p;


The rendering context would have a line from (10, 10) to (100, 10)



On Sat, Sep 29, 2012 at 10:19 AM, Rik Cabanier <cabanier at gmail.com> wrote:

>
>
> On Fri, Sep 28, 2012 at 1:19 PM, Dirk Schulze <dschulze at adobe.com> wrote:
>
>>
>> On Sep 28, 2012, at 12:17 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>>
>> >
>> >
>> > On Fri, Sep 28, 2012 at 9:31 AM, Dirk Schulze <dschulze at adobe.com>
>> wrote:
>> > Hi,
>> >
>> > Would it be possible to extend CanvasRenderingContext2D with the
>> functions:
>> >
>> > void addPath(Path path); - which adds a Path object to the current path
>> on Canvas?
>> > attribute Path currentPath; - that returns a copy of the current path,
>> or let you replace the current path with another Path object (not live)?
>> >
>> > These could possibly also replace clip(Path), fill(Path), stroke(Path),
>>  drawSystemFocusRing(Path path...), isPointInPath(Path path…).
>> >
>> > I like the 'op(path)' operators so I'd rather not see them go.
>> > 'currentPath' should return a read-only copy (and not be live)
>>
>> currentPath would not be live, no. But if you really want op(Path), then
>> it raises the question why we have path arithmetic in
>> CanvasRenderingContext2D at all. Then it should be completely separated
>> (which is not the case). What would be the sense for op(Path), if you have
>> currentPath attribute?
>>
>
> Currentpath could still be handy if you want to copy a path from one
> canvas to another, or if you have existing code that you are migrating.
> For instance, if you're going to use hit regions, it would be handy to
> have.
>
>>
>> >
>> >
>> > It needs to be clarified what happens for this case:
>> >
>> > var path = new Path();
>> > path.lineTo(20,20);
>> > ctx.currentPath = path;
>> > ctx.fill();
>> >
>> > The pendant on CanvasRenderingContext2D:
>> >
>> > ctx.beginPath();
>> > ctx.lineTo(20,20);
>> >
>> > would do a moveTo(20,20) internally. Should Path do the same? This
>> problem exists for fill(Path path) at the moment as well, if I did not miss
>> a line. Qt for instance adds a moveTo(0,0) at the beginning if no current
>> point was specified, other platforms behave differently.
>> >
>> > Yes, but the 'moveTo' would happen when you call the fill. The path
>> itself should just be geometry.
>> That would mean that the engine is fully aware of every operation in the
>> Path object. If the engine relies on the underlying graphic library (which
>> a lot of UIs do), then you are not aware of each segment anymore. Qt for
>> instance adds a moveTo(0,0) automatically if the first added segment is a
>> lineTo(…).
>>
>
> Yes, but only once you start executing the path in the canvas context.
> However, if we define a path as an 'atomic' operation, I agree that the
> 'moveTo' should be added to the path.
>
>
>>
>> > One question is what happen to the current path when you call
>> 'op(path)' since that is not defined in the current spec. I believe the
>> current path should be ignored and only the argument drawn.
>> That is what I would expect, but it is indeed not described yet.
>>
>> Dirk
>
>
>