Re: [whatwg] addPath and CanvasPathMethods

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

>
>
>
> On Thu, Mar 20, 2014 at 12:15 PM, Justin Novosad <junov@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.

Received on Thursday, 20 March 2014 21:55:31 UTC