[whatwg] CanvasRenderingContext2D with addPath, currentPath

[Rik Cabanier]

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