[whatwg] addPath and CanvasPathMethods

[Rik Cabanier]

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
anyway.