[whatwg] addPath and CanvasPathMethods

Rik Cabanier cabanier at gmail.com
Thu Mar 20 21:17:05 PDT 2014

On Thu, Mar 20, 2014 at 4:24 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Fri, Mar 21, 2014 at 8:15 AM, Justin Novosad <junov at google.com> wrote:
>> 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.
> An implementation can turn #2 into #1 if the paths obviously don't
> overlap. If they might overlap, the author probably shouldn't be doing the
> latter!

For this reason I don't particularly like the addPath API. It tricks
authors into thinking that they will get a union of the paths.

> TBH I don't see why authors would choose the latter approach.

I agree.
'addPath' will always cause the generation of a new path so if an author
chooses this strange approach, the retessellation will have to happen again

More information about the whatwg mailing list