[whatwg] Canvas and Paths

[Rik Cabanier]

On Wed, Mar 12, 2014 at 3:44 PM, Ian Hickson <ian at hixie.ch> wrote:

>
> On Thu, 28 Nov 2013, Rik Cabanier wrote:
> > On Thu, Nov 28, 2013 at 8:30 AM, Jürg Lehni <lists at scratchdisk.com>
> > wrote:
> > >
> > > 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.
>
> That's rather confusing, and a pretty good reason not to have a way to go
> from the current default path to an explicit Path, IMHO.
>
> Transformations affect the building of the current default path at each
> step of the way, which is really a very confusing API. The Path API on the
> other hand doesn't have this problem -- it has no transformation matrix.
> It's only when you use Path objects that they get transformed.
>

This happens transparently to the author so it's not confusing.
For instance:

ctx.rect(0,0,10,10);

ctx.scale(2,2); <- should not affect geometry of the previous rect
ctx.stroke(); <- linewidth is scaled by 2, but rect is still 10x10



> > > 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.
>
> I'm not sure what you're referring to here.
>

All graphics backends for canvas that I can inspect, don't apply the CTM to
the current path when you call a painting operator.
Instead, the path is passed as segments in the current CTM and the graphics
library will apply the transform to the segments.


> > It would be a very fast way to set a cached path in the graphics state
>
> What would the purpose of this be? You can just pass the path to the
> relevant functions instead, no?
>

I think we can defer the currentPath discussion for now.


> > 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"});
>
> Why not just add ctx.addHitRegion() calls after the fill and stroke calls?
>

That does not work as the second addHitRegion will remove the control and
id from the first one.
The 'add' operation is needed to get a union of the region shapes.


> On Fri, 6 Dec 2013, Jürg Lehni wrote:
> >
> > Instead of using getCurrentPath and setCurrentPath methods as a
> > solution, this could perhaps be solved by returning the internal path
> > instead of a copy, but with a flag that would prevent further
> > alterations on it.
> >
> > The setter of the currentPath accessor / data member could then make the
> > copy instead when a new path is to be set.
> >
> > This would also make sense from a a caching point of view, where storing
> > the currentPath for caching might not actually mean that it will be used
> > again in the future (e.g. because the path's geometry changes completely
> > on each frame of an animation), so copying only when setting would
> > postpone the actual work of having to make the copy, and would help
> > memory consummation and performance.
>
> I don't really understand the use case here.
>

Jurg was just talking about an optimization (so you don't have to make an
internal copy)