Before this change, cairo-perf-diff would work correctly only
if run from the top-level directory, (and if run from any other
directory it would not pull in the latest boilerplate and perf
files).
Previously, we were using rsync to recursively copy all files
from boilerplate and perf when doing the performance tests. This
had the fatal flaw that pre-built binaries would be hard coded to
link against the cairo library from $CAIRO_DIR with an absolute
path, (due to libtool rpath stuff).
By only copying git-managed files, we only get source and the compiled
binaries (or libtool wrappers) will now be hard-coded to link against
the library under test.
With the fancy new, incremental cairo-perf-diff we don't want to keep
resetting the same working tree back and forth between the old and new
versions and rebuilding everything all over again. So use two different
build directories instead of one.
This fixes the rebuild of the library itself, but the perf stuff is still
being rebuilt, (since it's being re-copied each time).
cairo-perf-diff now accepts a -f command-line option to force it to
re-generate performance results even if something exists in the cache
already. It also now uses raw mode and appends to the cached file
rather than rewriting the results.
Finally, it also now allows a -- option on the command line and passes
all the subsequent command-line options to cairo-perf. This is handy for
limiting cairo-perf to run only on a subset of the tests of interest.
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).
We don't need this at this deep level since callers can now
implement this limiting manually since stats.iterations is
now returned. Also, this was interfering with the -i option
to cairo-perf anyway.
Optimizes EXTEND_REPEAT, especially when DDBs are in use through the
use of PatBlt or manually expanding out the repeated blits (up to a
limit). Will still fall back to fallback code as necessary.
Make sure that all operations are correct (the operations chosen
are listed in cairo-win32-surface.c); in particular, deal with the extra
byte present in FORMAT_RGB24 surfaces correctly.
Also adds support for calling StretchDIBits to draw RGB24
cairo_image_surfaces directly.
It turns out that all of the callers want a box anyway, so this
simplfies the code in addition to being more honest to the name.
(For those new to the convention, a "box" is an (x1,y2),(x2,y2)
pair while a "rectangle" is an (x,y),(width,height) pair.)
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.
The perf tree's sha1 is now in the cache file name, so that
if the performance suite itself ever changes then new data
will be generated rather than using stale stuff from the cache.
Also, we now use the src tree's sha1 rather than the commit's
so that commits that don't change the src directory are also
treated as identical, (which they really should be as far as
performance of the library itself is concerned).
Instead of just discarding the worst 15% of the results, we now
do IQR-based detection and elimination of outliers. Also, instead
of reporting mean times we now report minimum and median times.
We still do compute the mean and standard deviation for the
detection of when results seem stable for early bailout. And we
do still report the standard deviation.
A statistician might complain that it looks funny to report the
median and the standard deviation together, (instead of median
and average absolute deviation from the median, say), but I liked
the standard deviation since it is always larger, so it might
ensure better separatation if we use it to determine when two
sets of results are sufficiently different to be interesting.
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.
Many thanks to Josh Triplett for help with theses fixes:
1. Simplify the usage of git to eliminate the fragile and nasty
stuff we were doing previously, (such as manually symlinking
things under .git rather than just using git-clone -s).
2. Don't try running latest cairo-perf with LD_LIBRARY_PATH
pointing to built cairo version. Apparently stupid libtool
and its use of rpath is foiling us here. Instead just run
whatever cairo-perf gets built as part of the source that
gets checked out.
This second point means that cairo-perf-diff won't yet be useful
for comparing the performance of old cairo revisions that pre-date
cairo-perf. I've since been reasing and we might be able to use
--disable-rpath to the configure script to get what we want.
