diff options
Diffstat (limited to 'docs/bitmap_pipeline.md')
| -rw-r--r-- | docs/bitmap_pipeline.md | 61 |
1 files changed, 61 insertions, 0 deletions
diff --git a/docs/bitmap_pipeline.md b/docs/bitmap_pipeline.md new file mode 100644 index 0000000..c12623c --- /dev/null +++ b/docs/bitmap_pipeline.md @@ -0,0 +1,61 @@ +# Bitmap Pipeline + +This pages details how bitmaps are moved from the renderer to the screen. + +The renderer can request two different operations from the browser: +* PaintRect: a bitmap to be painted at a given location on the screen +* Scroll: a horizontal or vertical scroll of the screen, and a bitmap to painted + +Across all three platforms, shared memory is used to transport the bitmap from +the renderer to the browser. On Windows, a shared section is used. On Linux, +it's SysV shared memory and on the Mac we use POSIX shared memory. + +Windows and Linux create shared memory in the renderer process. On Mac, since +the renderer is sandboxed, it cannot create shared memory segments and uses a +synchronous IPC to the browser to create them (ViewHostMsg\_AllocTransportDIB). +These shared memory segments are called TranportDIBs (device independent +bitmaps) in the code. + +Transport DIBs are allocated on demand by the render\_process and cached +therein, in a two entry cache. The IPC messages to the browser contain a +TransportDIB::Id which names a transport DIB. In the case of Mac, since the +browser created them in the first place, it keeps a map of all allocated +transport DIBs in the RenderProcessHost. The ids on the wire are then the inode +numbers of the shared memory segments. + +On Windows, the Id is the HANDLE value from the renderer process. On Linux the +id is the SysV key. Thus, on both Windows and Linux, the id is sufficient to map +the transport DIB, while on Mac is is not. This is why, on Mac, the browser +keeps handles to all the possible transport DIBs. + +Each RenderProcessHost keeps a small cache of recently used transport DIBs. This +means that, when many paint operations are performed in succession, the same +shared memory should be reused (as long as it's large enough). Also, this shared +memory should remain mapped in both the renderer and browser process, reduci ng +the amount of VM churn. + +The transport DIB caches in both the renderer and browser are flushed after some +period of inactivity, currently five seconds. + +### Backing stores + +Backing stores are browser side copies of the current RenderView bitmap. The +renderer sends paints to the browser to update small portions of the backing +store but, for performance reasons, when we want to repaint the whole thing +(i.e. because we switched tabs) we don't want to go to the renderer to redraw it +all. + +On Windows and Mac, the backing store is kept in heap memory in the browser. On +Windows, we use one advantage which is that we can use Win32 calls to scroll +both the window and the backing store. This is faster than scrolling ourselves +and redrawing everything to the window. + +On Mac, the backing store is a Skia bitmap and we do the scrolling ourselves. + +On Linux, the backing store is kept on the X server. It's a large X pixmap and +we handle exposes by directing the X server to copy from this pixmap. This means +that we can repaint the window without sending any bitmaps to the X server. It +also means that we can perform optimised scrolling by directing the X server to +scroll the window and pixmap for us. + +Having backing stores on the X server is a major win in the case of remote X. |