On Mon, Nov 4, 2013 at 3:17 PM, Dean Jackson <[email protected]> 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 <[email protected]> wrote: > > > On Mon, Nov 4, 2013 at 11:25 AM, Rik Cabanier <[email protected]> > wrote: > > > >> > >> > >> > >> On Mon, Nov 4, 2013 at 1:49 AM, Jürg Lehni <[email protected]> > 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 > >
