Changes

A new The content thread will handle composition. This thread will receive (s) renders web content into intermediate surfaces (layers) and sends these updates from to the content compositor thread, much as through layers transactions. We call client layers the chrome process receives updates from layers on the content process in e10s. Indeed, as much as possibleside, and host layers the ones on the shadow layers machinery developed compositor side. Layer classes are mostly responsible for e10s will be adapted defining the shape of the layer tree and own Compositable objects that are responsible for off-main-thread compositing. The design may need the logic of how to diverge in some places from transfer and composite the e10s approach: rendered web content (for exampleinstance handling tiling, on Androiddouble 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), updates from which handles the content thread to lifetime of the compositing thread need unerlying shared texture data and provides access read/write access to be asynchronous. it through Moz2D and TextureSource ('''note''': With the current code latter is how textures interact with the Compositor API)... this might not be Layers transaction makes sure that all of the editions applied to the case with client layer tree during a transaction are applied "at once" in the new frontendhost 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 even in cross-process communication. e10s uses the current same codeas regular OMTC, the cases except that require async PLayers could be fixed at the widget/android level toocontent and compositor threads are now in separate processes. We'll need to make a tradeoff.)