[whatwg] addPath and CanvasPathMethods

[Justin Novosad]

Sorry for the confusion, the point I was trying to make was unrelated to
the CTM question (almost). My point is that the tesselation of a path is
something that can be cached in a Path2D object.

If you do this, you can take advantage of the cached tessellation:
(apply tranform 1 to ctx)
ctx.fill(path1)
(apply tranform 2 to ctx)
ctx.fill(path2)

If you do it this way, the aggregated path needs to be re-tesselated each
time because the winding rule would need to be re-applied:
(apply tranform 1 to ctx)
ctx.addPath(path1)
(apply tranform 2 to ctx)
ctx.addPath(path2)
ctx.fill();

Technically, these two ways of drawing are not equivalent (depends on
compositing mode, transparency, and winding rule, overlaps between paths),
but they can be used to achieve similar things.  Nonetheless the second way
is detrimental to performance, and we'd be encouraging it by providing an
addPath method on the context.  Besides, if the dev really needs to add
paths together, it can be done inside an intermediate path object.



On Thu, Mar 20, 2014 at 2:52 PM, Dirk Schulze <dschulze at adobe.com> wrote:

>
> On Mar 20, 2014, at 7:44 PM, Justin Novosad <junov at google.com> wrote:
>
> > This would apply the CTM to the incoming path, correct?  I am a little
> bit concerned that this API could end up being used in ways that would
> cancel some of the performance benefits (internal caching opportunities) of
> Path2D objects.
>
> Where is the difference to fill(Path2D), stroke(Path2D) and clip(Path2D)?
> The path will always need to be transformed to the CTM. Graphic libraries
> usually do this already for you. The addPath() proposal is not different to
> that.
>
> Greetings,
> Dirk
>
> >
> >
> > On Thu, Mar 20, 2014 at 1:49 PM, Dirk Schulze <dschulze at adobe.com>
> wrote:
> > On Mar 20, 2014, at 6:31 PM, Rik Cabanier <cabanier at gmail.com> wrote:
> >
> > > addPath is currently defined on the Path2D object. [1]
> > > Is there a reason why it's not defined on CanvasPathMethods instead?
> That
> > > way this method is available on the 2d contest so you can append a
> path to
> > > the current graphics state.
> > >
> > > This would also negate the need for setCurrentPath.
> >
> > I am supportive for this idea! I agree that this would solve one of the
> reasons why I came up with currentPath for WebKit in the first place.
> >
> > Greetings,
> > Dirk
> >
> >
> > >
> > > 1:
> > >
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-path-addpath
> >
> >
>
>