| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Since this takes days to run now and should not find any bugs that are
not covered by the test-suite it seems like a pointless exercise.
Especially as I am trying to make a release!
|
|
Real applications that control their Drawable externally to Cairo are
'disadvantaged' by cairo-perf-trace when it creates a similar surface
for each new instance of the same Drawable. The difficulty in
maintaining one perf surface for every application surface is that the
traces do not track lifetimes for the application surfaces, so we would
just accumulate stale surfaces. The surface cache takes a different
approach and returns the same surface for each active Drawable, and
maintains a hold-over of the MRU 16 surfaces. This achieves 60-80% hit
rate with firefox, which is probably as good as can be expected.
Obviously for double-buffered applications we only every draw to freshly
created surfaces (and Gtk+ bypasses cairo to do the final copy -- the
ideal application would just use a push-group for double buffering, in
which case we would capture and replay the entire expose event).
To enable use of the surface cache whilst replaying use -c:
./cairo-perf-trace -c firefox-talos-gfx
|
|
In preparation to creating a new hub to control performance measuring
and reporting, move the current cairo-perf out of the way.
|
|
cairo-perf-chart takes multiple runs (currently it is limited to
prefiltered data sets) and pretty-prints a chart showing performace
improvements/regressions (in either ASCII or HTML) along with a
cairo-perf-chart.png
|
|
Redirecting all output was causing the build messages to be entangled with
the Performance Change html.
|
|
|
|
After a run, it can be useful to reprint the results, so add
cairo-perf-print to perform that task.
For the future, I'd like to move the performance suite over to the
git/perf style of single, multi-function binary.
The sequence of operations that I typically do are:
./cairo-perf-trace -r -v -i 6 > `git describe`.`hostname`.perf
./cairo-perf-diff-files REVA REVB
./cairo-perf-print REVA
./cairo-perf-compare-backends REVA
which misses the caching available with cairo-perf-diff. 'make html' is
almost what I want, but still too prescriptive. However, that does need to
be addressed for continuous performance monitoring.
Along the perf lines, those sequence of operations become:
./cairo-perf record -i 6
./cairo-perf report
./cairo-perf report REVA REVB
./cairo-perf report --backends="image,xlib,gl" REVA REVB
./cairo-perf report --html REVA REVB
Also we want to think about installing the cairo-perf binary. So we want
to differentiate when run inside a git checkout.
|
|
|
|
It seems adding the explicit dependencies to encourage it to rebuild
components from other parts of the source tree removed the automagic
dependency of libcairoperf.la. So add it to the list. Maybe this is not
the correct solution, but it works again for now.
|
|
Rather than complicating cairo-perf to extend it to perform both micro-
and macro-benchmarks, simply run the two binaries in succession during
make perf.
For bonus points, consider whether we should hook cairo-perf-trace into
cairo-perf-diff.
|
|
Update the build rules and add the dependences for the libraries built in
other parts of cairo.
|
|
Add a variant of cairo-perf that measures the time to replay traces.
|
|
|
|
Use the new API Behdad exposed in 1.8 to precompute a glyph string using
Cairo and then benchmark cairo_show_glyphs(). This is then equivalent to
the text benchmark but without the extra step of converting to glyphs on
every call to cairo_show_text() i.e. it shows the underlying glyph
rendering performance.
|
|
Use CAIRO_LDFLAGS in order to pull in additional link options, such as
--coverage.
|
|
The SDL backend makes invalid assumptions about SDL_Surface locking
semantics and doesn't deal correctly with the unpremultiplied pixel
format supported by SDL. Removed as per discussion on the mailing list.
http://lists.cairographics.org/archives/cairo/2009-February/016595.html
|
|
A minor variation on cairo-perf-diff-files that compares tests with the
same name for multiple backends.
|
|
These tests look at the differences in code paths
hit by filling paths that are rectilinear (or not) and
pixel aligned (or not) with the even-odd and non-zero
fill rules. The paths are not simple, so they don't
hit the special case quad/triangle tessellator.
|
|
We don't have one just for this purpose. The only other
path with many intersections that gets actually rendered is zrusin-another,
but that might be sped up in the future (say by identifying
collinearities up front or something like that.)
|
|
If automake detects the use of cairo_perf_LDADD in an unused conditional
that overrides the default - so we need to manually set cairo_perf_LDADD.
|
|
The attached patch makes the SDL tests compile under Mac OS X. The
problem is:
1) that <SDL_main.h> should be included in files that define the main
function for SDL Mac OS X programs (this is not true with the upcoming
SDL 1.3 release).
2) that -lSDLmain, because it is statically linked, needs the Cocoa
framework in the LDADD of the main program. Again, 1.3 will not require
this.
|
|
Test lots of rectangles and recursion path construction.
|
|
Inspired by http://labs.trolltech.com/blogs/2007/08/31/rasterizing-dragons/
and http://en.wikipedia.org/wiki/Dragon_curve, add a performance test case
to measure drawing this space-filling fractal curve.
|
|
Include a COPYING inside perf/, test/, util/ to clarify the licensing
conditions beneath the respective directories. This is because cairo
itself (libcairo.so) is LGPL-2.1/MPL-1.1 but that only relates to src/.
The auxiliary source files are under a mix of free licenses and we wish to
be clear just what license applies to each file.
In particular, cairo-trace needs to include the GPL terms and conditions.
|
|
Behdad wants to include the feature with 1.10, so we enable it as early as
possible in 1.9 dev cycle to generate as much feedback as possible.
The first change is to use "<cairo>" as being a name unlikely to clash
with any real font names.
This reverts commits:
a824d284be23793a5c48b9ae833dcb7b2d5fff80,
292233685534aed712dfd45e8ccf498b792ce496,
e0046aaf417a61da008dc6374871fa3687ba94ab,
f534bd549e1e2283735d1eabb60c015a5949a735.
|
|
This performance test relied on the recently-removed ability
to select the internal twin-based font family with a name of
"cairo".
Presumably, we'll want to bring this performance case back when
some other means of requesting that font face is added.
|
|
|
|
Generate a cairo-perf-diff graph for a series of commits in order to be
able to identify significant commits. Still very crude, but minimally
functional.
|
|
Add a new test case to Cairo for checking the performance of Cairo's
equivalent to GDK's gdk_pixbuf_composite_color() operation. That is an
operation that happens to be extremely useful when viewing or editing
transparent images so I think it is important that it is as fast as
possible.
|
|
Add the performance test case to compare the speed of filling a rounded
rectangle (one with camphered corners) as opposed to an ordinary
rectangle. Since the majority of the pixels are identical, ideally the two
cases would take similar times (modulo the additional overhead in the more
complex path).
|
|
|
|
Use a common build/Makefile.am.common file.
|
|
Fixes automake warning.
|
|
Fixes automake warnings
|
|
Such that we don't rely on more GNU extensions accidentally.
|
|
Otherwise, these files were being omitted from the tar files.
|
|
Add EXEEXT to TESTS so that mingw builds the correct target.
|
|
libtool exists in the top level build directory, but in a couple of
places we refer to the top level source directory.
|
|
|
|
Avoid O(N*N) loop in traps_extract_region by letting us hand pixman
an array of rects all at once.
|
|
This is needed on Solaris, but also works on Linux.
|
|
Otherwise these programs stick around and break distclean,
distcheck, and hence release-publish targets.
|
|
|
|
MacSlow noticed that cairo_paint_with_alpha is much slower than
it should be, (and jrmuizel has a nice plan for fixing the
performance bug).
|
|
|
|
Although cairo-perf is not written to perform explicit failure testing of
cairo, it does generate long sequences of cairo operations which often
trigger unexpected errors. By including it with make check, it becomes
even easier for the programmer to check that one has not broken cairo in
terms of expected behaviour or performance.
|
|
|
|
The CAIRO_PERF_ENVIRONMENT slipped into the middle of the command line
instead of at the start.
|
|
That is:
1) no VALGRING vs VG abbreviations
2) setting TARGETS and ITERS on the make command line works now
|
|
|
