Re: [whatwg] Path API feedback

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.


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


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

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.


> The resulting 'path' will once again have no winding. This is very 
> confusing and extremely hard to implement

I don't understand why it's hard to implement. It's just the non-Path API, 
but stored away for future use.


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

Can you elaborate? (I think I may have asked already, in which case, my 
apologies for asking again.)


> > 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. For instance: skia: 
> http://skia-autogen.googlecode.com/svn/docs/html/classSkPathEffect.html 
> lib2geom: http://wiki.inkscape.org/wiki/index.php/WorkingWith2GeomFAQ 
> Direct2D: 
> http://msdn.microsoft.com/en-us/library/windows/desktop/dd756653(v=vs.85).aspx#path_geometries

I'm confused. Are these examples of how to make confusing APIs, or 
examples of how the current API is confusing? Those look really, really 
complicated relative to what Canvas looks like today.


On Thu, 5 Sep 2013, Rik Cabanier wrote:
> 
> The problem happens when you call fill or stroke multiple times.
> [...]
> Now I want to create a region that covers what was drawn.
> [...]
> 'p' won't describe the same area as what was filled.

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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 17 September 2013 17:21:18 UTC