Platform/GFX/OffMainThreadCompositing: Difference between revisions

Platform/GFX/OffMainThreadCompositing (view source)

Revision as of 13:24, 6 October 2014

688 bytes added , 6 October 2014

→‎Design

Nical

Confirmed users

138

edits

@@ Line 16: / Line 16: @@
 [[File:LayersRefactoring.png|thumb|650px|Gfx layers class diagram]]
-A new thread will handle composition. This thread will receive updates from the content thread, much as the chrome process receives updates from the content process in e10s. Indeed, as much as possible, the shadow layers machinery developed for e10s will be adapted for off-main-thread compositing. The design may need to diverge in some places from the e10s approach: for example, on Android, updates from the content thread to the compositing thread need to be asynchronous.  ('''note''': With the current code ... this might not be the case with the new frontend, and even in the current code, the cases that require async PLayers could be fixed at the widget/android level too.  We'll need to make a tradeoff.)
+The content thread(s) renders web content into intermediate surfaces (layers) and sends these updates to the compositor thread through layers transactions. We call client layers the layers on the content side, and host layers the ones on the compositor side. Layer classes are mostly responsible for defining the shape of the layer tree and own Compositable objects that are responsible for the logic of how to transfer and composite the rendered web content (for instance handling tiling, double buffering, etc.). There are client and host implementations for compositables as well. For compositables to remain backend-independent, we abstract the backend specific code out behin the texture abstraction (also split between the client and host instances), which handles the lifetime of the unerlying shared texture data and provides access read/write access to it through Moz2D and TextureSource (the latter is how textures interact with the Compositor API).
+Layers transaction makes sure that all of the editions applied to the client layer tree during a transaction are applied "at once" in the host layer tree so that we always composite content in a coherent state.
+The communication mechanism is based on IPDL, which abstracts out cross-thread and cross-process communication. e10s uses the same code as regular OMTC, except that the content and compositor threads are now in separate processes.
 =Plan=