[whatwg] Questions regarding Path object
cabanier at gmail.com
Tue Aug 20 12:09:22 PDT 2013
> 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
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
. However as my post points out, if the rectangle and the circle interact,
the result is not what is expected.
It is much more common to combine shapes which will always give you the
effect you're looking for.
> Also, it's not at all clear to me that there's really a distinction
> between a "shape" and a "path". They're really the same thing -- sets of
> path segments.
No. A shape is no longer a group of line segments.
You *could* convert it to such a thing but that requires a bunch of complex
math (ie http://www.youtube.com/watch?v=OmfliNQsk88)
For now, I'm not proposing to add that to the canvas API.
> What distinguishes them is not anything intrinsic to them,
> it's the behaviour when you combine segments.
> Thus the clearer solution, IMHO, insofar as there's a problem, is to add
> methods that describe the various ways to combine paths.
Paths don't have winding so if you combine them, it will have to be part of
the methods that union them.
The resulting 'path' will once again have no winding. This is very
confusing and extremely hard to implement
> Right now we have two options (ignoring the text parts of the path API):
> concatenating path segments, and concatenating path segments after having
> first outlined one of them.
FYI the outlining algorithm is also not correct. It suffers from the same
issue that strokes are segments.
> On the long run I think it would make sense to add other methods, e.g. one
> combining two or more paths together such that the resulting path would
> outline the union of the "insides" of the provided paths, or the
> intersections, or whatnot.
I think that would be much more confusing and difficult to implement.
I didn't come up with this on my own :-). This is done by graphics
libraries that offers path manipulation support.
More information about the whatwg