W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2013

Re: [whatwg] CanvasRenderingContext2D with addPath, currentPath

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 4 Nov 2013 15:52:58 -0800
Message-ID: <CAGN7qDCokDyoZSPP0V1BePZj8BTjJ0L5DgnBKKP2Vo=Ke0OmKg@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:13 UTC