Re: [whatwg] CanvasRenderingContext2D with addPath, currentPath

Oh, I misunderstood you, Rik.

I meant to say that it I think it would make more sense if the path was in the current transformation matrix, so it would represent the same coordinate values in which it was drawn, and could be used in the same 'context' of transformations applied to the drawing context later on.

So this is not how most implementations currently have it defined.

One reason why I think this would make more sense: Matrices don't just affect the geometry of the path, they also influence the size and shape of the stroke (circle or ellipse?), the fill (gradients), etc.

I feel the current implementation has limited use, or I don't understand the use-cases for it.

Jürg

On Nov 10, 2013, at 02:47 , Rik Cabanier <cabanier@gmail.com> wrote:

> 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@scratchdisk.com> wrote:
> 
> On Nov 4, 2013, at 20:25 , Rik Cabanier <cabanier@gmail.com> wrote:
> 
> > On Mon, Nov 4, 2013 at 1:49 AM, Jürg Lehni <lists@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
>

Received on Thursday, 28 November 2013 16:30:20 UTC