On Wed, Feb 11, 2009 at 11:42 PM, Evan Martin <[email protected]> wrote:
> > (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? we found it to be surprisingly expensive in this context. perhaps it is a property of the windows VM, but if we allocate, memcpy, free the virtual memory for the transport DIB, we seem to make a lot more work for windows. if instead use the small recycling cache, windows is far happier. "the transport DIB stays hot, which keeps the memcpy cheap" :) > > 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. CreateCompatibleBitmap creates a DDB, which is taxed against the memory limits of the desktop. the desktop has a very small address space, so DDBs should only be used as temporary scratch space by applications. you can really screw over your windows box if you allocate a number of large DDBs :-( we should probably look into using directx (if available) to implement our backingstore buffers. > > 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. agl suggested using shared memory for the transport DIB that is compatible with the X server. that means MIT-SHM instead of posix shared memory (see base/shared_memory). we should be able to blt from this ARGB surface onto the device-dependent backingstore. i guess that might require something like Xrender. -darin > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
