[whatwg] CanvasRenderingContext2D with addPath, currentPath

[Rik Cabanier]

I think that is reasonable.
Most implementations have the path stored in user space and it's less
confusing for authors.

So the APIs stay:

Path getCurrentPath();
void setCurrentPath(Path);

with the path in user space. There should be some normative text that the
current default path [1] is transformed by the inverse of the CTM.
If the CTM is non-invertible, the path is empty for getCurrentPath and
ignored for setCurrentPath.

1:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#drawing-paths-to-the-canvas


On Wed, Nov 6, 2013 at 3:30 AM, Jürg Lehni <lists at scratchdisk.com> wrote:

>
> On Nov 4, 2013, at 20:25 , Rik Cabanier <cabanier at gmail.com> wrote:
>
> > On Mon, Nov 4, 2013 at 1:49 AM, Jürg Lehni <lists at scratchdisk.com>
> wrote:
> > > What's the use case?
> > >
> > > I intentionally didn't add this to the spec when I was adding the last
> set
> > > of path-related features, because it seems entirely redundant with Path
> > > objects. I thought we'd want people to move away from using the
> implicit
> > > path, rather than making it more powerful.
> >
> > I like this feature a lot. One advantage to not underestimate is the
> amount of effort it takes to change existing code to make use off the new
> Path feature, while staying backward compatible with older browsers that
> don't implement this spec. For example, in Paper.js it took only three
> added lines of code to use cached paths if they exist rather than redrawing
> them each time
> >
> > Do you think getCurrentPath should return a path in user space or in the
> current transformation matrix?
>
> I think it should be in user space, without the transformations factored
> in. The current behavior is confusing, and I wonder what it's use case
> would be. In the meantime I realized I have to revert the change that I've
> outlined above for exactly this reason...
>
> Jürg