[cairo] Cairo 1.3 performance loss
cworth at cworth.org
Wed Jan 31 13:32:59 PST 2007
On Wed, 31 Jan 2007 11:42:34 -0800, "Daniel Amelang" wrote:
> I've got a perf test laying around that I made back in the days I was
> working on the matrix optimizations (cairo_rectangle calls
> user_to_backend and user_to_device_distance several times).
Perfect, that's just the thing I was thinking of writing.
> If it's what you're looking for, just say the word and I'll push it.
Too late, I've already pushed it.
And here are the results from doing cairo-perf-diff (on my x86 laptop)
on every snapshot from 1.2.4 through 1.3.12, (no output fro any given
command means cairo-perf-diff saw no change it considers significant):
$ ./cairo-perf-diff 1.2.4 1.2.6 -- rectangles
$ ./cairo-perf-diff 1.2.6 1.3.2 -- rectangles
image-rgba rectangles-512 6.28 6.12% -> 5.60 5.25%: 1.12x speedup
image-rgb rectangles-512 6.37 3.61% -> 5.84 1.48%: 1.09x speedup
$ ./cairo-perf-diff 1.3.2 1.3.4 -- rectangles
image-rgba rectangles-512 5.60 5.25% -> 7.55 1.28%: 1.35x slowdown
image-rgb rectangles-512 5.84 1.48% -> 7.61 1.09%: 1.30x slowdown
xlib-rgb rectangles-512 9.81 2.87% -> 11.47 3.88%: 1.17x slowdown
xlib-rgba rectangles-512 9.78 3.50% -> 11.42 0.91%: 1.17x slowdown
$ ./cairo-perf-diff 1.3.4 1.3.6 -- rectangles
$ ./cairo-perf-diff 1.3.6 1.3.8 -- rectangles
$ ./cairo-perf-diff 1.3.8 1.3.10 -- rectangles
$ ./cairo-perf-diff 1.3.10 1.3.12 -- rectangles
So, we did something to improve this case a bit between 1.2.6 and
1.3.2, but then we regressed all that improvement (and more) in the
One might not be surprised to find that 1.3.4 is indeed when the new
tessellator landed. In fact, I even said in the release notes for that
We should point out that there is some potential for slowdown in this
But Daniel replied by saying that the numbers I reported to back that
up weren't convincing. It's nice to see some fairly convincing numbers
in the above.
So, how to fix this? One idea, (as I already spelled out earlier), is
to add a rectangle primitive to cairo_path_fixed_t. Then, we can
easily detect cases that can be handled with more efficient code than
the full tessellator.
And for the (extremely common) case of a single rectangle, we can just
use the existing tessellate_convex_quad.
So that's quite easy to do and will cover this perf cases, (and
hopefully the regressions that people are seeing in the GTK+ theme
There are certainly other potential paths that could be affected by
this performance regression, but they get harder to handle
correctly. For example, as soon as there are multiple rectangles in
the path we would have to start worrying about the rectangles
interacting with each other, (for example, subtracting from each
other). We could still optimize some of those things, but it will
depend on people identifying actual regressions in things like that
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20070131/d15474c6/attachment.pgp
More information about the cairo