This test shows that drawing a 100x100 single-pixel wide box outline is
currently 5 to 16 times slower when using the natural cairo_stroke() as
compared to a rather awkward cairo_fill() of two rectangles.
[ # ] backend-content test-size min(ticks) min(ms) median(ms) stddev. iterations
[ 0] image-rgba box-outline-stroke-100 301321 0.218 0.219 0.39% 5
[ 1] image-rgba box-outline-fill-100 18178 0.013 0.013 0.43% 5
[ 0] xlib-rgba box-outline-stroke-100 379177 0.275 0.276 1.39% 6
[ 1] xlib-rgba box-outline-fill-100 83355 0.060 0.060 0.17% 5
The map for this test case was originally demonstrated as a
performance problem in this mozilla bug report:
A very slow SVG file with <path>s
https://bugzilla.mozilla.org/show_bug.cgi?id=332413
I obtained permission from the creator of the original file to
include the data here, (see comments in world-map.h for details).
This new test case is the 0th polygon polygon from Zack Rusin's
recent cairorender program as made avaialable here:
http://ktown.kde.org/~zrusin/examples/cairorender.tar.bz2
This polygon contains about 1000 coordinates and looks like a
hand-drawn version of the word another.
This test is really just for hammering the double to fixed-point conversion
(in _cairo_fixed_from_double) that happens as doubles from API calls gets
translated into internal cairo fixed-point numbers.
This will finally allow us to very easily add lots of other
tests that will similarly involve iterating over the various
sources and operators of interest.
This changes the perf test output format to be a little more human friendly,
reporting times in ms instead of seconds. It also adds a test number
that could be used in the future for specifying an explicit test to run
(test number, target surface, test name, and size uniquiely identify
a test).
Also adds a few paint tests.
We do this by adding a new cairo_perf_timer_set_finalize function and
in the case of the xlib backend passing a callback to that function
that does a 1x1 XGetImage.
1. Remove all the alarm/signal code, which just isn't doing what we want for some reason.
Instead, for now we'll simply run for a fixed number of iterations, (perhaps we
can tune that per test later).
2. Before computing mean and stdandard deviation of runs, sort them all and discard the
top and bottom 20% of the values.
Now the standard deviation for the paint test is generally 2% or less.
