Per https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/irLAQ8f8uGk

Initial migration of wiki content over to src/docs

There will be a follow-up CL to ensure docs are following chromium’s style guide, links are fixed, etc. The file auditing was becoming too much for a single change and per Nico’s suggestion, it seems to be better to do

+ Bulk import with initial prune.
+ Follow-up CLs to clean up the documentation.

So that each CL has its own purpose.

BUG=none

Review URL: https://codereview.chromium.org/1309473002

Cr-Commit-Position: refs/heads/master@{#345186}

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.