[whatwg] CanvasRenderingContext2D with addPath, currentPath

Rik Cabanier cabanier at gmail.com
Mon Nov 4 14:47:35 PST 2013

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
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
used by these methods (without affecting the
itself). When the intended path is the current default
it is not affected by the transform. (*This is because transformations
already affect the **current default
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).


More information about the whatwg mailing list