[whatwg] addPath and CanvasPathMethods

[Rik Cabanier]

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.


> 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?

I do not like the addPath method myself, but if it's offered on Path2D,
it's reasonable to have it on the context.
I was experimenting porting canvg to use the Path2D object and the
implementation would be much cleaner if there was a way to set the path in
the graphics state.


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