[cairo] Extents of degenerate paths

[Behdad Esfahbod]

On Thu, 2007-05-10 at 09:53 +0200, David Turner wrote:
> 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,

Yes, seems like we agree on the interface, and an implementation of that
interface which is both fast enough and returns zero extents on
zero-width stroke is quite feasible.

Anyone volunteering to nurture David's mentioned patch?


Cheers,

behdad


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