how drawing works
I wrote a post explaining how drawing works, from the sandboxed renderer up the screen. It's more complicated than you might expect — caches of shared memory regions and backing stores and IPC, oh my. A couple people contacted me off-list to thank me, so perhaps you'll find it interesting too.
If you read more of the thread you get a bonus smirk about a 48mb memory limit in Windows. Why 48mb? There's gotta be some good reason; it seems like a weird number to chop at.
At the end I discuss how we plan to draw on X. It may even not be so bad on X via a network, which is a nice hope. (Adam develops from San Francisco on a computer in Mountain View via remote X, so he gets to be our guinea pig.) In some far-off future you could imagine the renderer process could send display lists to the browser so it could be converted into normal X calls, but for now we have images.
Here's a question for any X hackers who may read this: if you're repeatedly transferring small dirtied regions to X is there anything smarter you can do than using a low-bpp pixmap to transfer it to the server and then using X render to copy that to the screen's format? I imagine you could maybe somehow compress data and push it to a pixmap that the X server would then decompress. Is there anything smarter we could do than adding a —low-bandwidth flag to trade off image quality (like 16bpp) for performance? NX is pretty amazing but I kinda wish it was just built in.
Now that I'm trawling around, this doc on X performance is a good read as is the thread from the NX announcement.