Add tag so entry will actually appear in blog

[cworth.org] / src / exa / understanding_rectangles.mdwn

diff --git a/src/exa/understanding_rectangles.mdwn b/src/exa/understanding_rectangles.mdwn
index 8c92fc402be27bcfc9ca071c4f5e50720c792a59..f7cf290e80d66926c51e0e07a8280fe5b8731a44 100644 (file)
--- a/src/exa/understanding_rectangles.mdwn
+++ b/src/exa/understanding_rectangles.mdwn
@@ -54,13 +54,13 @@ cairo-based rectangles test case looked about like this:
        }
 
 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.
 
@@ -72,7 +72,7 @@ protocol tracing[*] revealed that XFillRectangle is batching requests
 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