Re: [whatwg] CanvasRenderingContext2D with addPath, currentPath

On Thu, Nov 28, 2013 at 8:30 AM, Jürg Lehni <lists@scratchdisk.com> wrote:

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

No worries, it *is* confusing. For instance, if you emit coordinates and
then scale the matrix by 2, those coordinates from getCurrentPath will have
a scale of .5 applied.


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

I'm unsure what you mean. Browser implementations? If so, they definitely
do store the path in user coordinates.
The spec currently says otherwise [1] though.


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

Yes, in order to replay or store a path, you would need to save the CTM.
Because set/getCurrentPath work in user coordinates, the user would have to
make sure to set the CTM before setting the path.

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


I agree it's not the most useful API but it will be helpful. From one of
the previous message:

It would be a very fast way to set a cached path in the graphics state

and:

Another use case is to allow authors to quickly migrate to hit regions.

ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill();
... // lots of complex drawing operation for a control
ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke();


To migrate that to a region (with my proposed shape interface [1]):

var s = new Shape();

ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); s.add(new
Shape(ctx.currentPath));
...
ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); s.add(new
Shape(ctx.currentPath, ctx.currentDrawingStyle));

ctx.addHitRegion({shape: s, id: "control"});


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


>
> 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 Friday, 29 November 2013 05:03:38 UTC