[whatwg] Path API feedback

[Rik Cabanier]

On Wed, Oct 16, 2013 at 3:01 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 18 Sep 2013, Rik Cabanier wrote:
> > On Tue, Sep 17, 2013 at 10:20 AM, Ian Hickson <ian at hixie.ch> wrote:
> > > On Tue, 20 Aug 2013, Rik Cabanier wrote:
> > > > > On Sat, 23 Mar 2013, Rik Cabanier wrote:
> > > > > >
> > > > > > The current path APIs suffer from conflating path segments and
> > > > > > geometry. To fix this, I proposed to modify the API so path just
> > > > > > describe the path segments.
> > > > > >
> > > > > >
> http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/
> > > > >
> > > > > I disagree with the premise of this post -- it's not the case that
> > > > > you never want to add segments. It is in fact quite common to add
> > > > > segments to a path -- that's what constructing a path is.
> > > >
> > > > I disagree. How many times does an author want to add segments to an
> > > > existing path?
> > >
> > > Pretty much every time they create a path with more than one segment.
> >
> > Maybe I phrased that wrong. The existing path is a path that was created
> > earlier (and could have already been used to draw). It's not often that
> > you would want to append to such a path.
>
> Right, the current API is only about building paths, not about later
> combining paths. We haven't added that feature yet. That would be covered
> by: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21835
>
>
> > > > Let's say an application stores a circle in a path and now want to
> > > > draw a rectangle too. You propose that the application just appends
> > > > the rectangle.
> > >
> > > No, not necessarily. It depends on what they want to do. If they want
> > > a single path that is constructed of a circle and a rectangle in the
> > > same way that it would be if they did:
> > >
> > >    x.beginPath();
> > >    x.arc(...);
> > >    x.rect(...);
> > >    x.fill();
> > >
> > > ...then yeah, they should just append the rectangle. But if they want
> > > the same effect as:
> > >
> > >    x.beginPath();
> > >    x.arc();
> > >    x.fill();
> > >    x.rect(...);
> > >    x.fill();
> > >
> > > ...then they should not just append them, since as you say, it won't
> > > work.
> >
> > Yes, but for hit regions, you would have to calculate the area that
> > these 2 fill operations covered. This is why we need the extra 'union'
> > API.
>
> I don't think anyone is arguing that we don't eventually need such an API.
>
>
> > > Once the Path API is implemented, we can add any number of features,
> > > such as adding a path so as to form the union of both paths, adding a
> > > path so as to form the intersection of both paths, etc.
> >
> > OK. In order to make that possible, 'addPath', 'addPathByStrokingPath',
> > 'addText' and 'addTextByStrokingText' should be cut from the interface.
>
> Why?
>

Paths are a construct that can be filled with a fill rule or stroked. After
this, they are no longer paths but regions of a certain color.
The same is true for text. (Your recent addition that describes a stroke as
sweeping a line following the path, is starting to align with that.)

The path object should represent the path in the graphics state. You can't
add a stroked path or text outline to the graphics state and then
fill/stroke it.
currentPath which was added by WebKit and Blink, makes that clear.

> > Sure, for that you need a new API function, e.g. union, which as I've
> > > mentioned before, I think would be a logical addition to the API in
> > > due course. But I don't think we should add features too quickly, lest
> > > we get too far ahead of browsers.
> >
> > That sounds reasonable.
> > So please remove the APIs such as AddPathByStrokingPath that rely on
> > these difficult algorithms.
>
> I don't understand why one implies the other. Can you elaborate on your
> reasoning here?


Those APIs have to know how to turn strokes and text into paths (which is
not trivial and no UA does by default).
In addition if you want to have useful output (= not getting unexpected
interactions of the winding rules), the APIs would need to use
planarization for stroke and text outlines.
See http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/ for
a description of the issue.