[cairo-bugs] [Bug 31589] Very high cpu usage of _cairo_bentley_ottmann_tessellate_polygon() in transmission-gtk

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=31589

--- Comment #3 from M Joonas Pihlaja <jpihlaja at cc.helsinki.fi> 2010-11-14 02:49:26 PST ---
If you want ghosted text rendered at 0.5 alpha, then just render the text at
0.5 alpha.  This avoids all use of the stroker. :)  There are likely other
methods to get shadows or ghosted text suitable for you, not involving the
stroker, so if using a temporary image surface isn't a viable option, then
perhaps investigating those in the context of your app might be a way forward? 
Please drop by the #cairo irc channel on freenode or post to the cairo-l
mailing list if feel like it.

Regarding overuse of the tessellator, here's approximately what happens when
you stroke a path using the xlib backend: 1) The outline of the path is
computed as a polygon. 2) The stroker notices it cannot prove that there are no
self-intersections in the resulting polygon so it calls on the tessellator to
remove the intersections and return a list of non-overlapping trapezoids.
In fact, due to how the outline's polygon is constructed, it's nearly always
the case that there are self-intersections in the polygon.  3) The trapezoids
are composited to the target surface.

The main change in 1.10 is in step two where the self-intersections are
removed.  Before, the stroker just didn't care so it would emit trapezoids
directly, disregarding possible overlaps.  The end result when composited is an
annoying "sparkling" at the edges where the outline polygon crosses itself.  To
mitigate the slowness we've implemented a fast path for rectilinear strokes,
but unfortunately it doesn't kick in if the path to stroke has curves or the
line join- and cap-styles aren't suitable.

For the image backend the story is slightly different in that the rasterization
method (new in 1.10) used by the image backend can deal with self-intersecting
polygons just fine, so there's no need for tessellating the outline polygon.

I'm really sorry your stroking code was impacted so badly.  If you could send
us a cairo-trace of your application for the cairo-traces collection it could
help us find a solution for stroking in the future that addresses the
self-intersection bugs yet isn't slow as molasses on trapezoid backends. 
Traces of real world performance and regressions like this are key in directing
the development focus.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.