[whatwg] CanvasRenderingContext2D with addPath, currentPath

Rik Cabanier cabanier at gmail.com
Sat Sep 29 10:19:56 PDT 2012

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

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

More information about the whatwg mailing list