docs/bitmap_pipeline.md

   1 # Bitmap Pipeline
   2
   3 This pages details how bitmaps are moved from the renderer to the screen.
   4
   5 The renderer can request two different operations from the browser:
   6 * PaintRect: a bitmap to be painted at a given location on the screen
   7 * Scroll: a horizontal or vertical scroll of the screen, and a bitmap to painted
   8
   9 Across all three platforms, shared memory is used to transport the bitmap from
  10 the renderer to the browser. On Windows, a shared section is used. On Linux,
  11 it's SysV shared memory and on the Mac we use POSIX shared memory.
  12
  13 Windows and Linux create shared memory in the renderer process. On Mac, since
  14 the renderer is sandboxed, it cannot create shared memory segments and uses a
  15 synchronous IPC to the browser to create them (ViewHostMsg\_AllocTransportDIB).
  16 These shared memory segments are called TranportDIBs (device independent
  17 bitmaps) in the code.
  18
  19 Transport DIBs are allocated on demand by the render\_process and cached
  20 therein, in a two entry cache. The IPC messages to the browser contain a
  21 TransportDIB::Id which names a transport DIB. In the case of Mac, since the
  22 browser created them in the first place, it keeps a map of all allocated
  23 transport DIBs in the RenderProcessHost. The ids on the wire are then the inode
  24 numbers of the shared memory segments.
  25
  26 On Windows, the Id is the HANDLE value from the renderer process. On Linux the
  27 id is the SysV key. Thus, on both Windows and Linux, the id is sufficient to map
  28 the transport DIB, while on Mac is is not. This is why, on Mac, the browser
  29 keeps handles to all the possible transport DIBs.
  30
  31 Each RenderProcessHost keeps a small cache of recently used transport DIBs. This
  32 means that, when many paint operations are performed in succession, the same
  33 shared memory should be reused (as long as it's large enough). Also, this shared
  34 memory should remain mapped in both the renderer and browser process, reduci ng
  35 the amount of VM churn.
  36
  37 The transport DIB caches in both the renderer and browser are flushed after some
  38 period of inactivity, currently five seconds.
  39
  40 ### Backing stores
  41
  42 Backing stores are browser side copies of the current RenderView bitmap. The
  43 renderer sends paints to the browser to update small portions of the backing
  44 store but, for performance reasons, when we want to repaint the whole thing
  45 (i.e. because we switched tabs) we don't want to go to the renderer to redraw it
  46 all.
  47
  48 On Windows and Mac, the backing store is kept in heap memory in the browser. On
  49 Windows, we use one advantage which is that we can use Win32 calls to scroll
  50 both the window and the backing store. This is faster than scrolling ourselves
  51 and redrawing everything to the window.
  52
  53 On Mac, the backing store is a Skia bitmap and we do the scrolling ourselves.
  54
  55 On Linux, the backing store is kept on the X server. It's a large X pixmap and
  56 we handle exposes by directing the X server to copy from this pixmap. This means
  57 that we can repaint the window without sending any bitmaps to the X server. It
  58 also means that we can perform optimised scrolling by directing the X server to
  59 scroll the window and pixmap for us.
  60
  61 Having backing stores on the X server is a major win in the case of remote X.