OLD | NEW |
(Empty) | |
| 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. |
OLD | NEW |