[cairo] Extents of degenerate paths

[Behdad Esfahbod]

On Wed, 2007-05-09 at 15:20 +0200, David Turner wrote:
> On Mon, 07 May 2007 20:07:15 -0400, "Behdad Esfahbod" <behdad at behdad.org> said:
> > On Mon, 2007-05-07 at 14:46 -0400, T Rowley wrote:
> > > In Mozilla SVG, I've run across the case where the code needs to check 
> > > the extents of a single diagonal line.  With stroke_width set to zero I 
> > > get back 0,0,0,0 rather than the a tight bounding box for the line.
> > > 
> > > Investigating other cases I see similar results - testcase code 
> > > attached.  While the fill extent cases could be argued correct in 
> > > returning 0,0,0,0 (should be documented if this is the intended result), 
> > > it seems that the line extents should be a bounding box for the path.
> > 
> > I think the current output is correct and should be documented.  Also
> > may make sense to add cairo_path_extents() to do what you want.
> > 
> 
> Please, please, do *not* consider this "correct", this is going to result
> in *large* performance problems. I'll try to clarify things here: there
> are essentially two ways to define what the "extents" are:
> 
> 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.

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


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