[whatwg] CanvasRenderingContext2D with addPath, currentPath

[Rik Cabanier]

On Mon, Nov 4, 2013 at 3:17 PM, Dean Jackson <dino at apple.com> wrote:

> FWIW - I think that
> ctx.currentPath != ctx.currentPath
> is a horrible mistake and we should fix WebKit.


Should we fix it by replacing it with getters/setters or by having it
return the actual copy (which could be hard to implement in a performant
way)?


> On 4 Nov 2013, at 2:47 pm, Rik Cabanier <cabanier at gmail.com> wrote:
>
> > On Mon, Nov 4, 2013 at 11:25 AM, 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?
> >>
> >
> > Answering my own question, when reading the canvas spec [1], it should be
> > in user space:
> >
> > When the intended path is a
> > Path<
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path
> >
> > object,
> > the coordinates and lines of its subpaths must be transformed according
> to
> > the CanvasRenderingContext2D<
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#canvasrenderingcontext2d
> >
> > object's current transformation
> > matrix<
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#transformations
> >
> > when
> > used by these methods (without affecting the
> > Path<
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path
> >
> > object
> > itself). When the intended path is the current default
> > path<
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#current-default-path
> >,
> > it is not affected by the transform. (*This is because transformations
> > already affect the **current default
> > path*<
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#current-default-path
> >*
> > when
> > it is constructed, so applying it when it is painted as well would result
> > in a double transformation*.)
> >
> >
> > In light of this, does anyone have objections to these 2 new methods:
> >
> > Path getCurrentPath();
> >
> > void setCurrentPath(Path);
> >
> >
> > With the path in user space (so it is not affected by the CTM).
> >
> > 1:
> >
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#drawing-paths-to-the-canvas
>
>