Confirmed users
138
edits
(→Design) |
|||
Line 16: | Line 16: | ||
[[File:LayersRefactoring.png|thumb|650px|Gfx layers class diagram]] | [[File:LayersRefactoring.png|thumb|650px|Gfx layers class diagram]] | ||
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= | =Plan= |