[Linux] Avoid compositor pause and make it thread safe
Categories
(Core :: Widget: Gtk, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox124 | --- | unaffected |
| firefox125 | --- | unaffected |
| firefox126 | --- | fixed |
People
(Reporter: stransky, Assigned: stransky)
References
Details
(Keywords: topcrash, Whiteboard: [stockwell disable-recommended])
Crash Data
Attachments
(9 files, 1 obsolete file)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
- We should avoid compositor pause but rather render to offscreen surface after XWindow hide.
- We need to make compositor/nsWindow calls thread safe
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 1•1 year ago
|
||
We need a bit rework how we manage popup close and sync compositor shutdown for it.
Beta will go with hotfix in Bug 1882021 where we force-update XWindow after popup open.
Nightly is partially covered by Bug 1882462 (destroy layer manager on popup close).
To correctly fix it we should update GtkCompositorWidget to be thread safe, fix rendering offscreen to EGLWindow and make sure XWindow is updated by GtkCompositorWidget::EnableRendering() wihout previous GtkCompositorWidget::DisableRendering() call.
We should not use GtkCompositorWidget::DisableRendering() to hold rendering to invalid XWindow as it leads to UI freezes/timeouts.
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 4•1 year ago
|
||
Updated•1 year ago
|
| Assignee | ||
Comment 5•1 year ago
|
||
- Merge nsWindow::DisableRendering() and nsWindow::OnUnmap() as it handles the same event (widget unmap)
- Remove nsWindow map/unmap mContainer handlers and call them directly from mContainer. It ensures correct order
where we stop rendering / clear resources and then release them.
Depends on D204066
| Assignee | ||
Comment 6•1 year ago
|
||
- Clean up native rendering resources stored at GtkCompositorWidget and mSurfaceProvider
- Call SendResume() to all rendering backends, it leads to nullptr result from nsWindow::GetNativeData(NS_NATIVE_EGL_WINDOW) from compositor
thread (as nsWindow is unmapped) and rendering backend will create offscreen rendering buffer then.
Depends on D204067
| Assignee | ||
Comment 7•1 year ago
|
||
- Rename mDestroyMutex to mWindowVisibilityMutex to make clear it protects window visibility changes
- Make mIsMapped atomic - we want to read it from rendering thread. We don't protect nsWindow::IsMapped() getter by mutex
as we know backend code can render to hidden window safely.
Depends on D204068
| Assignee | ||
Comment 8•1 year ago
|
||
Depends on D204069
| Assignee | ||
Comment 9•1 year ago
|
||
Depends on D204071
| Assignee | ||
Comment 10•1 year ago
|
||
It makes sure underlying native surface (XWindow/wl_surface) stays allocated until compositor thread finishes rendering and returns
drawing target to us.
Depends on D204072
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
Updated•1 year ago
|
| Assignee | ||
Comment 13•1 year ago
|
||
| Assignee | ||
Updated•1 year ago
|
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Assignee | ||
Comment 16•1 year ago
|
||
Comment 17•1 year ago
|
||
Comment 18•1 year ago
•
|
||
Backed out for causing perma mda failures @ test_getUserMedia_basicScreenshare.html
Backout link: https://hg.mozilla.org/integration/autoland/rev/e992e79977545c04b7fef1c5a911c0216e9b4c08
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Assignee | ||
Comment 21•1 year ago
|
||
I can reproduce the layout/reftests/margin-collapsing/inline-horizontal-1.html failure, thanks.
Updated•1 year ago
|
| Assignee | ||
Comment 22•1 year ago
|
||
Depends on D204073
| Assignee | ||
Updated•1 year ago
|
Comment 23•1 year ago
|
||
Comment 24•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/c48c0bac61e6
https://hg.mozilla.org/mozilla-central/rev/69d389710699
https://hg.mozilla.org/mozilla-central/rev/69770ebd8903
https://hg.mozilla.org/mozilla-central/rev/8a52d2e3479d
https://hg.mozilla.org/mozilla-central/rev/54a6067c4d01
https://hg.mozilla.org/mozilla-central/rev/5550caf7701f
https://hg.mozilla.org/mozilla-central/rev/b6316d0df80a
Comment 25•1 year ago
|
||
The assertion failure is still happening as you can see here.
Should we reopen this bug or file a new one?
| Comment hidden (Intermittent Failures Robot) |
| Assignee | ||
Comment 27•1 year ago
|
||
Will look at it ASAP, Thanks.
Comment 28•1 year ago
|
||
| Assignee | ||
Comment 29•1 year ago
|
||
(In reply to Sandor Molnar[:smolnar] from comment #25)
The assertion failure is still happening as you can see here.
Should we reopen this bug or file a new one?
Let's track it at Bug 1882538.
| Comment hidden (Intermittent Failures Robot) |
Comment 31•1 year ago
|
||
| bugherder | ||
Comment 32•1 year ago
|
||
Backed out the latest commit because many crashes with the signature [@ moz_container_wayland_get_egl_window] have been reported after this landed: https://hg.mozilla.org/mozilla-central/rev/e1c37d37e8e47757a40b72a59eca6d4c7415acfa
Crash report: https://crash-stats.mozilla.org/report/index/99f132fc-9ff0-4303-bc97-aaf840240324
MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(wl_container->ready_to_draw) (We can't draw to surface!)
Top 10 frames of crashing thread:
0 libxul.so moz_container_wayland_get_egl_window widget/gtk/MozContainerWayland.cpp:726
1 libxul.so nsWindow::GetNativeData widget/gtk/nsWindow.cpp:3433
2 libxul.so mozilla::widget::GtkCompositorWidget::GetEGLNativeWindow widget/gtk/GtkCompositorWidget.cpp:120
2 libxul.so mozilla::gl::GLContextEGL::CreateEGLSurfaceForCompositorWidget gfx/gl/GLContextProviderEGL.cpp:340
2 libxul.so mozilla::wr::RenderCompositorEGL::CreateEGLSurface gfx/webrender_bindings/RenderCompositorEGL.cpp:58
2 libxul.so mozilla::wr::RenderCompositorEGL::Resume gfx/webrender_bindings/RenderCompositorEGL.cpp:203
3 libxul.so mozilla::wr::RendererOGL::Resume gfx/webrender_bindings/RendererOGL.cpp:294
3 libxul.so mozilla::wr::RenderThread::Resume gfx/webrender_bindings/RenderThread.cpp:884
3 libxul.so mozilla::wr::WebRenderAPI::Resume gfx/webrender_bindings/WebRenderAPI.cpp:774
4 libxul.so mozilla::wr::RenderThread::RunEvent gfx/webrender_bindings/RenderThread.cpp:715
| Comment hidden (Intermittent Failures Robot) |
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 34•1 year ago
|
||
Looks like we need more patches here, Thanks.
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 36•1 year ago
|
||
Split window configuration (mGdkWindow setup) and compositor resume and use mutex to protect window config only.
That ensures we always have valid mGdkWindow but we don't deadlock if compositor resume is called from map/unmap during
forced EGLSurface update.
Updated•1 year ago
|
| Assignee | ||
Comment 37•1 year ago
|
||
Depends on D205633
Comment 38•1 year ago
|
||
The bug is linked to a topcrash signature, which matches the following criterion:
- Top 10 desktop browser crashes on nightly
For more information, please visit BugBot documentation.
Comment 40•1 year ago
|
||
Comment 41•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/79a66bf59a9a
https://hg.mozilla.org/mozilla-central/rev/ba04f6471cad
Updated•1 year ago
|
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
Description
•