[cairo] Extents of degenerate paths

[David Turner]

Hi Behdad,

> > A - in one case, they correspond to the convex hull of the geometric
> >     shape being filled / stroked.
> 
> No.  For stroke extents, you need to keep all the stroke parameters
> (miter, etc) into account.  If you ignore them, there's no different
> between fill extents and stroke extents.  If you really want hull
> extents, that is fill extents.
> 

Maybe I wasn't clear, but I was *including* all the stroke parameters in
what I call the convex hull. So I think we agree on this one. While more
complex than a fill, computing the corresponding extents is simpler than
doing the whole tessellation (especially when you're not using miter but
round corners, but that's a different topic...)

> > B - in the other, they correspond exactly to what is going to be drawned
> > 
> > there is no difference between these two except for a few extreme cases
> > like a zero-sized stroke, or overlapping counter-winded paths which
> > annihilate each other.
> 
> This is not true.  In fact the case of zero-sized stroke can be
> immediately detected and returned.  The hard part really is the stroke
> parameters.
> 

My point is that I don't see any benefit of requiring tesselation to get
the extents of a path fill or stroke. If you want to be able to detect
zero-sized strokes and return an empty box with it, so be it, as long as
it doesn't make the rest of the code slow.

And for the really hard part (self-annihilating counter paths), I don't
think there is any practical purposes in detecting them and returning
an empty box here.

Hope we agree on this one,

- David


> 
> behdad
> 
> 
> > Computing A can be done very fast, even with the sophisticated stroking
> > performed by Cairo. On the other hand, B basically *requires* tessellation
> > of the path/stroke which is something significantly slower.
> > 
> > I submitted several months ago a patch that drastically simplified and sped
> > up the extents computations in Cairo, by computing A instead of B. It hasn't
> > been integrated because there was no test case for this in the performance
> > suite, and nobody had time to look at it... Still, I stand by my point.
> > 
> > Keep in mind that this has the potential to speed up SVG rendering, since
> > any non-trivial document will require computing the extents of any path
> > (in 'original' units) before drawing it properly (in device units).
> > 
> > I would thus strongly suggest to make behaviour A the documented default,
> > and to simplify the extents computation code as soon as possible.
> > 
> > And in case you'd ask, I don't have time to resubmit a different patch.
> > 
> > Cheers,
> > 
> > - David Turner
> > > 
> > > -- 
> > > behdad
> > > http://behdad.org/
> > > 
> > > "Those who would give up Essential Liberty to purchase a little
> > >  Temporary Safety, deserve neither Liberty nor Safety."
> > >         -- Benjamin Franklin, 1759
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > cairo mailing list
> > > cairo at cairographics.org
> > > http://cairographics.org/cgi-bin/mailman/listinfo/cairo
> -- 
> behdad
> http://behdad.org/
> 
> "Those who would give up Essential Liberty to purchase a little
>  Temporary Safety, deserve neither Liberty nor Safety."
>         -- Benjamin Franklin, 1759
> 
> 
>