More the large slowdowns to the end. This has two pleasing effects:
1. There is symmetry between large speedups at the top, and large
slowdowns at the bottom, with long bars -> short bars -> long bars.
2. After a cairo-perf-diff run the largest slowdowns are immediately
visible on the console. What better way to flag performance
regressions?
Add a CAIRO_PERF_OUTPUT environment variable to cause cairo-perf to first
generate an output image in order to manually check that the test is
functioning correctly. This needs to be automated, so that we have
absolute confidence that the performance tests are not broken - but isn't
that the role of the test suite? If we were ever to publish cairo-perf
results, I would want some means of verification that the test-suite had
first been passed.
The warning is repeated in the error message if we fail to find any
traces, and now that we search a path it is likely that some elements do
not exist. Thus we annoy the user with irrelevant, non-fatal warnings.
Still looking for suggestions for the most appropriate home for the system
wide cairo-traces dir...
The original stroke only contains a single subpath. Self-intersection
removal particularly affects strokes with multiple curved segments, so add
a path that encompasses both straight edges and rounded corners.
Andrea Canciani (ranma42) found another instance of my broken 'degenerate'
curve-to as line-to optimisation. All I can say is when I do something
wrong, at least I'm consistent!
This test case highlights the bug in the rel-curve-to path.
There are many common scenarios, mostly involving overlapping glyphs,
for which to guarantee correct rendering we have to composite the glyphs
via an explicit mask. That is instead of just blending the glyphs on to
the destination, we have to add the glyphs to a mask, and then composite
that mask+source with the destination.
By performing the check on whether the operator is supported prior to
acquiring the context, we do not need to handle the error part way
through the context setup. This makes the code much cleaner, and save
some work for the unsupported cases.
In order to catch infinite loops whilst replaying and converting vector
surfaces to images (via external renderers) we need to also install
alarms around the calls to finish() and get_image().
The stroker code is liable to wedge when passed
dash patterns which don't advance the dash offset
due to limited precision arithmetic. This test
attempts to hit all the places in the stroker where
that can happen.
Reported on the cairo mailing list by Hans Breuer:
http://lists.cairographics.org/archives/cairo/2009-June/017506.html
As pointed out by Andrea, and now tested by test/degenerate-curve-to, a
curve-to that begins and ends on the same point may extend further due to
its control points. It can not be simply replaced with a degenerate
line-to. In order to do so we will need more extensive degeneracy
checking, ala _cairo_spline_init().
Andrea Canciani (ranma42) pointed out a second bug in the curve-to as
line-to optimisation, that is a curve starting and finishing on the same
point is not necessarily degenerate. This test case exercises 5 different
curves that start and end on the same point.
Looks like ghostscript has a similar buggy optimization like we
just fixed in cairo. I'm just waiting on a new bugzilla account
from bugs.ghostscript.com after which I plan to report the bug
there.
This test anticipates a future optimization, (already pushed
upstream but not pulled yet), with a buggy implementation
of replacing curve_to with line_to.
This is a major performance improvement for GL even on non-TNL hardware
(i915), as we get to emit one giant DrawArrays and make GL drivers love us.
Now we're actually faster than not having the glyph cache.
Before glyph cache (HP 945GM):
[ 0] gl firefox-20090601 238.103 238.195 0.35% 5/6
After:
[ 0] gl firefox-20090601 68.181 76.735 5.46% 6/6
In a discussion on IRC, attention was drawn to a dubious comment in
_cairo_xlib_show_glyphs() - the precise details of which have passed
out of the collective memory.
In bed2701, I removed the explicit finish of the paginated's target
surface, since as a wrapper it did not explicitly own the surface and so
should not be calling finish(). However, we do need to propagate errors
from the backing surface, such as PDF, which will only be detected during
the implicit finish in the final destroy. So check to see it we hold the
last reference to the target (and so our destroy will trigger the implicit
finish) and call the finish explicitly and check the error status
afterwards.
If we know the CPU can read pointers atomically, then we can simply peek
into the cached_xrender_formats to see if we already have a match, before
taking the mutex. (Acquiring the mutex here is a minor nuisance that
appears on the callgrind profiles.)
In order to efficient store small images, we need to pack them into a
large texture. The rtree handles allocation of small rectangles out of a
much larger whole. As well as tracking free rectangles, it can also be
used to note which parts of the texture are 'pinned' -- that is have
operations currently pending and so can not be modified until that batch
of operations have been flushed. When the rtree is full, i.e. there is no
single free rectangle to accommodate the allocation request, it will
randomly evict an unpinned block large enough to fit the request. The
block may comprise just a single glyph, or a subtree of many glyphs. This
may not be the best strategy, but it is an effective start.
The fallback for degenerate splines is to treat them as a line-to, so if
the spline is straight, we can just replace it with a simple line-to by
treating as degenerate.
