Confirmed users
699
edits
Gecko:CrossProcessLayers: Difference between revisions
Jump to navigation
Jump to search
→Implementation
No edit summary |
|||
| Line 87: | Line 87: | ||
The process architecture for the first implementation will look something like the following. | The process architecture for the first implementation will look something like the following. | ||
[[File:Cross-process-layers-v0.png|thumb|650px|v0 process architecture]] | [[File:Cross-process-layers-v0.png|thumb|650px|v0 process architecture]] | ||
The big boxes are processes and the circles next to squiggly lines are threads. <code>PFoo</code> refers to an IPDL protocol, and <code>PFoo(Parent|Child)</code> refers to a particular actor. | |||
Layer trees shared across processes may look something like | |||
[[File:Layer-trees-v0.png|thumb|650px|v0 layer tree]] | |||
Like the first diagram, big boxes are processes. The circled item in the Content process is a decoder thread. The arrows drawn between processes indicate the direction that layer-tree updates will be pushed. All updates will be made through a <code>PLayers</code> protocol. This protocol will likely roughly correspond to a "remote layer subtree manager". A <code>ShadowContainerLayer</code> corresponds to the "other side" of a remote subtree manager; it's the entity that receives layer tree updates from a remote process. The dashed line between the decoder thread and the Content main thread just indicates their relationship; it's not clear what Layers-related information they'll need to exchange, if any. | |||
It's worth calling out in this picture the two types of (non-trivial) shared leaf layers: <code>ShmemLayer</code> and <code>PlaceholderLayer</code>. A <code>ShmemLayer</code> will wrap IPDL <code>Shmem</code>, using whichever backend is best for a particular platform (might be POSIX, SysV, VRAM mapping, ...). Any process holding on to a <code>ShmemLayer</code> can read and write the buffer contents within the constraints imposed by [[IPDL/Shmem|<code>Shmem</code> single-owner semantics]]. This means, e.g., that if Plugin pushes a <code>ShmemLayer</code> update to Content, Content can twiddle with Plugin's new front buffer before pushing the update to Chrome, and similarly for Chrome before pushing Chrome-->Compositor. We probably won't need this feature. | |||
A <code>PlaceholderLayer</code> refers to a "special" layer with a buffer that's inaccessible to the process with the <code>PlaceholderLayer</code> reference. Above, it refers to the video decoder thread's frame layer. When the decoder paints a new frame, it can immediately push its buffer to Compositor, bypassing Content and Chrome (which might be blocked for a "long time"). In Compositor, however, the <code>PlaceholderLayer</code> magically turns into a <code>ShmemLayer</code> with a readable and writeable front buffer, so there new frames can be painted immediately with proper Z-ordering wrt content and chrome layers. Content can arbitrarily fiddle with the <code>PlaceholderLayer</code> in its subtree while new frames are still being drawn, and on the next Content-->Chrome-->Compositor update push, the changes to <code>PlaceholderLayer</code> position/attributes/etc. will immediately take effect. | |||
'''TODO strawman PLayers protocol''' | |||
'''TODO example of PLayers::Update(cset) propagation''' | |||