(I'm not an expert on the drawing pipeline but I recently learned a bit about it and I thought I'd write down notes before I forget. Hopefully someone like Darin who understands better than me will fill in the holes.)
Chromium's WebKit draws in a sandboxed subprocess and it ends up on the screen. How does it get there? == Transport DIB WebKit/Skia want an 32-bit ARGB memory buffer to paint into. We create such a buffer (which can be as small as the requested dirty paint rect), called the transport DIB, and put it in shared memory between the renderer and browser process. Conceptually a given renderer needs one of these per paint operation, but it seems each renderer process keeps a simple cache of the last two shared memory regions used (I assume to prevent needing to rapidly set up these regions repeatedly?). I wonder, how expensive is it to allocate shared memory? Code to reference: chrome/renderer/render_process.cc == Backing Store On the browser side, we keep a full-page backing store for a tab's contents. This is incrementally updated as the renderer sends painted bits of the page. Aside from the obvious double-buffering benefit (to reduce flicker), one aspect of this design to keep in mind is that it makes the browser's drawing decoupled from the renderer -- even if a renderer decides to hang, the browser still has an image of the page's contents that it can use to display. This also means when we switch tabs we can update the screen immediately. The browser keep around a cache 5 of these backing stores. There's a TODO comment to make this dynamic with the memory available on the system. At one point these backing stores were device dependent bitmaps -- that is, in the format most convenient for blitting to the screen quickly -- but there was some problem with this I've already forgotten (I'm glad I'm typing this out!). It does appear we attempt to match the bitmap to the screen's format, but we don't use the CreateCompatibleBitmap API. Code to reference: chrome/browser/renderer_host/backing_store* == Linux Currently on both Linux and Mac we're just serializing the image bytes over IPC (rather than using a transport DIB). This is a temporary hack. On Linux we also have the X server to consider. It's effectively a third process that needs to be involved in getting bits shuffled around for drawing. Here's where I believe we're heading. - The transport DIB's format is more or less fixed. We can use the same shared memory pattern like the Windows code to get the data into the browser process. - The backing stores should live on the X server. This allows the server to redraw them quickly, and operations like scrolling a portion of the bitmap to happen entirely server-side. It is unclear to me whether we'll need to do conversions between the transport DIBs and the backing store format, or where that conversion will happen -- perhaps it can be done by X but otherwise we can do it in the browser process. I imagine if the paint updates are small this would still behave ok across a network, as we'd only be sending the dirty redrawn bits over the wire. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
