[cairo] Cairo 1.3 performance loss

[Carl Worth]

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
	Speedups
	========
	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
	Slowdowns
	=========
	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
1.3.4 snapshot.

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
snapshot:

	We should point out that there is some potential for slowdown in this
	snapshot.

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
testing).

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
first.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20070131/d15474c6/attachment.pgp