- From: Rik Cabanier <cabanier@gmail.com>
- Date: Mon, 4 Nov 2013 15:52:58 -0800
- To: Dean Jackson <dino@apple.com>
- Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Jürg Lehni <lists@scratchdisk.com>, Ian Hickson <ian@hixie.ch>
On Mon, Nov 4, 2013 at 3:17 PM, Dean Jackson <dino@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@gmail.com> wrote: > > > On Mon, Nov 4, 2013 at 11:25 AM, 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? > >> > > > > 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 > >
Received on Monday, 4 November 2013 23:53:23 UTC