Server side backing stores
As mentioned earlier in discussing drawing, we keep a backing store of contents of recent tabs, both for performance and for multi-process rendering reasons. In the X world, the right place to store these backing stores is on the X server. Consider Adam, who works in San Francisco using a machine 35 miles away in Mountain View — when he scrolls his browser window down by one pixel, we want his local machine to move all the pixels up by one row, and only ship the new row of pixels up from Mountain View.
So r10369 does this, and more. Even when running locally, we can avoid serializing all those pixels over X socket by using X shared memory. And we can avoid conversion between pixel formats (the renderer draws on an 32-bit ARGB memory buffer) by putting merging the newly-drawn regions and the off-screen buffer onto the X server, which in theory has access to video hardware for doing blitting.
The one hiccup is that if the screen doesn't match the pixel format of our buffer exactly, plain X can't do conversions. The X render extension, famously introduced for doing alpha compositing, can, so we use that if available, and then there's a series of fallback for slower cases (no shared memory, no X render). Some of the code is likely wrong and also slower than necessary, but it can be fleshed out once we benchmark.
(PS: Apparently AJAX has supplanted X for client-server UI technology. It's too bad we can't do more complicated computations server-side with X...)