Gecko:CrossProcessLayers: Difference between revisions

Jump to navigation Jump to search
Line 12: Line 12:
* Since we're pushing changes across threads anyway, we might as well push them across process boundaries at the same time, so push them all the way to the GPU process
* Since we're pushing changes across threads anyway, we might as well push them across process boundaries at the same time, so push them all the way to the GPU process
* Therefore, the GPU process maintains a set of shadow layer trees and is responsible for compositing them
* Therefore, the GPU process maintains a set of shadow layer trees and is responsible for compositing them
** Question: why "set of" rather than "layer tree"?  Latter option would have main thread maintain "master tree", push updates of this to compositor process.  Scheduling could be done by setting "frame-rate goal" attributes on layers (or something).
* Compositing a shadow layer tree either results in a buffer that's rendered into a window, or a buffer that is later composited into some other layer tree
* Compositing a shadow layer tree either results in a buffer that's rendered into a window, or a buffer that is later composited into some other layer tree
** We can reduce VRAM usage at the expense of increased recomposition work by recompositing a content process layer tree every time we composite its parent layer tree and not having a persistent intermediate buffer
** We can reduce VRAM usage at the expense of increased recomposition work by recompositing a content process layer tree every time we composite its parent layer tree and not having a persistent intermediate buffer
*** Question: would this require a synchronous request to content to re-composite, or would composition be done on content pixels in shared memory?
** We can control the scheduling of content layer tree composition
** We can control the scheduling of content layer tree composition


Confirmed users
699

edits

Navigation menu