[whatwg] CanvasRenderingContext2D with addPath, currentPath
cabanier at gmail.com
Fri Nov 1 17:01:54 PDT 2013
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
You can also set a path, again in device space (meaning that the current
CTM would not be applied).
var ctx = ...getContext("2d");
var p = ctx.currentPath;
Path p would contain a line from (20, 20) to (200, 20)
var p = new Path();
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>
>> > Hi,
>> > Would it be possible to extend CanvasRenderingContext2D with the
>> > 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
>> > 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
> 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.
More information about the whatwg