Only restart the GPU process when the app comes back to the foreground
Categories
(GeckoView Graveyard :: Sandboxing, defect, P2)
Tracking
(firefox99 fixed)
| Tracking | Status | |
|---|---|---|
| firefox99 | --- | fixed |
People
(Reporter: agi, Assigned: jnicol)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 1 obsolete file)
When the GPU is killed or crashes while the app is in the background, we should not restart it as we don't need it and might make the app more prone to background kills unnecessarily.
| Assignee | ||
Comment 1•3 years ago
|
||
Rather than lazily attempting to connect the SurfaceAllocator if
required whenever the content process tries to allocate a surface,
instead give control over the connection to the parent process. Make
it connect after the content process has been created, and
additionally after rendering has being reinitialized following a GPU
process loss. This aligns with how we reconnect various IPDL protocols
between content processes and the compositor.
This avoids content processes attempting to connect to the GPU
process' surface allocator before it has been started, which is
important for the next patch in this series where we want to delay
restarting the GPU process if the app is in the background.
If the content process attempts to allocate a surface inbetween the
old connection dying and the new connection being made then it will
gracefully fail. If the GPU process dies again whilst the connection
is being made then that is okay, a new connection will be made shortly
afterwards.
Updated•3 years ago
|
| Assignee | ||
Comment 2•3 years ago
|
||
If the android system kills the GPU process to free memory while the
app is in the background, then we want to avoid immediately restarting
the GPU process.
To achieve this, we make GPUProcessManager keep track of whether it is
in the foreground or background. If HandleProcessLost() gets called
while in the background then we destroy the existing compositor
sessions as before, but instead of immediately relaunching the process
then reinitializing content bridges, just set a flag saying we need to
do so. If the flag is set when the app later gets foregrounded then we
continue where we left off.
While we're here, rename the functions RebuildRemoteSessions() and
RebuildInProcessSessions() to DestroyRemoteCompositorSessions() and
DestroyInProcessCompositorSessions(), to better reflect what they
actually do: the "rebuilding" part occurs later on. Also update the
mega-comment documenting the restart sequence, as it was somewhat
outdated.
In case a caller of EnsureGPUReady() gets called before the foreground
signal arrives (eg in nsBaseWidget::CreateCompositorSession() due to a
refresh tick paint), make EnsureGPUReady() launch the GPU process
itself if the GPU process is enabled but not yet launched.
Additionally, guard against a null pointer deref if the compositor has
been destroyed when the widget receives a memory pressure event. This
is now more likely to occur as there may be a gap between the
compositor being destroyed and recreated.
Depends on D139041
Updated•3 years ago
|
Comment 4•3 years ago
|
||
Backed out for causing gtest failures on TestMediaDataDecoder.cpp
Failure log: https://treeherder.mozilla.org/logviewer?job_id=368369219&repo=autoland
Backout link: https://hg.mozilla.org/integration/autoland/rev/2e99f053a6ded321087bce88466a1e466b91a36e
Updated•3 years ago
|
Comment 6•3 years ago
|
||
| bugherder | ||
| Assignee | ||
Updated•3 years ago
|
Comment 7•3 years ago
|
||
Moving GPU process bugs to the new GeckoView::Sandboxing component.
Updated•1 year ago
|
Updated•1 year ago
|
Description
•