W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

Re: [whatwg] Questions regarding Path object

From: Rik Cabanier <cabanier@gmail.com>
Date: Tue, 20 Aug 2013 12:09:22 -0700
Message-ID: <CAGN7qDB2d6y7CSpcpxjdqimdB2CdOVvh3BW16kanpFwtEDY5gQ@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Dirk Schulze <dschulze@adobe.com>, whatwg <whatwg@lists.whatwg.org>, Jürg Lehni <lists@scratchdisk.com>, Simon Pieters <simonp@opera.com>
>
> 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?

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.
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
Received on Tuesday, 20 August 2013 19:09:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC