-[[tag cairo exa xorg]]
+[[meta title="Understanding the cairo rectangles performance test case"]]
-# Understanding the cairo rectangles performance test case
+[[tag cairo exa xorg]]
About a month ago (can it have been that long already?) I started an
effort to try to [baseline EXA performance on an r100
}
That is, each rectangle was being filled individually. I experimented
-with changing this so that many calls were made to cairo_rectangle for
-each call to cairo_fill. The mysterious EXA slowdown I had been
+with changing this so that many calls were made to `cairo_rectangle` for
+each call to `cairo_fill`. The mysterious EXA slowdown I had been
chasing went away, but only because everything became a lot slower. It
turns out there's a bad performance bug in cairo when it converts from
-a list of rectangular trapezoids to a pixman_region. Cairo's pixman
+a list of rectangular trapezoids to a `pixman_region`. Cairo's pixman
doesn't expose a function for "create region from list of rectangles"
-so cairo is calling a pixman_region_union function once for every
+so cairo is calling a `pixman_region_union` function once for every
rectangle. This looks like an unnecessary O(n**2) algorithm to
me. Fortunately that should be a simple thing to fix.
while XRenderFillRectangles is not. That's a rather nasty trap for an
unwary Xlib coder like myself. I added batching in chunks of 256
rectangles around XRenderFillRectangles and it started behaving
-precisely like XRenderFillRectangles.
+precisely like XFillRectangles.
Finally, I eliminated some non-determinism from the rectangles test
case. Originally, it was written to choose randomly-sized rectangles