[whatwg] addPath and CanvasPathMethods

[Justin Novosad]

On Thu, Mar 20, 2014 at 4:22 PM, Rik Cabanier <cabanier at gmail.com> wrote:

>
>
>
> On Thu, Mar 20, 2014 at 12:15 PM, 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 tessellation of a path is
>> something that can be cached in a Path2D object.
>>
>
> Path2D does not contain the winding or a hint that it will be used for
> fill/clip or stroking. I'm unsure if it gives you enough information to
> cache tessellation before you call a marking operation.
>

It doesn't give you enough information, you would only get a cache hit the
second time the path is drawn with the same winding rule and fill/stroke
parameters. clipping probably should not be baked-in.

>
>
>> 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.
>>
>
> How would using intermediate path objects not be detrimental to
> performance?
>

It would be detrimental. It is just that devs would not be tempted to do
that unless they needed to, as opposed to having addPath right on the CRC2D.