Closed
Bug 1489902
Opened 5 years ago
Closed 5 years ago
[Wayland] Opengl/Webrender hangs in eglSwapBuffers()
Categories
(Core :: Graphics, defect, P2)
Tracking
()
RESOLVED
FIXED
mozilla65
Tracking | Status | |
---|---|---|
firefox65 | --- | fixed |
People
(Reporter: rmader, Assigned: stransky)
References
(Blocks 1 open bug, )
Details
(Whiteboard: [gfx-noted])
Attachments
(1 file)
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0 Build ID: 20180904093908 Steps to reproduce: Note: this is not a duplicate of bug 1480755. WebGL works fine/smooth again and both tested versions have the fix. Enable accelerated layers (or webrender) on firefox-wayland 62 or flatpak nightly (in gnome wayland session). Fedora 28, mesa 18.1.3, intel ivybridge Actual results: Flatpak nightly always hangs after the message "Attempting load of libEGL.so" Ff 62 also hangs on first try ("Attempting load of libEGL.so"). After closing and trying again, sometimes it starts with the message: Attempting load of libEGL.so WebGL(0x7fb76bcd1000)::ForceLoseContext WebGL(0x7fb76bcd1800)::ForceLoseContext Expected results: It should properly start in both cases
Updated•5 years ago
|
Updated•5 years ago
|
Priority: -- → P3
Whiteboard: [gfx-noted]
Reporter | ||
Comment 1•5 years ago
|
||
This is got solved for me on recent versions of nightly (flatpak 64) Still see it in fedora 29, firefox-wayland 62, though.
Assignee | ||
Comment 2•5 years ago
|
||
Yes, I can see that. It's frozen in Compositor thread, there's a backtrace: #0 0x00007ffff7b603d1 in poll () at /lib64/libc.so.6 #1 0x00007ffff66c1b79 in poll (__timeout=-1, __nfds=1, __fds=0x7fffd18b7780) at /usr/include/bits/poll2.h:46 #2 0x00007ffff66c1b79 in wl_display_poll (display=display@entry=0x7ffff7868300, events=events@entry=1) at src/wayland-client.c:1710 #3 0x00007ffff66c35fc in wl_display_dispatch_queue (display=0x7ffff7868300, queue=0x7fffd01daa00) at src/wayland-client.c:1783 #4 0x00007fffce03510b in dri2_wl_swap_buffers_with_damage (drv=<optimized out>, disp=0x7fffd0120000, draw=0x7fffd01dc000, rects=0x0, n_rects=0) at drivers/dri2/platform_wayland.c:943 #5 0x00007fffce025df6 in eglSwapBuffers (dpy=0x7fffd0120000, surface=<optimized out>) at main/eglapi.c:1261 #6 0x00007fffeba323e8 in mozilla::gl::GLLibraryEGL::fSwapBuffers(void*, void*) const (this=0x7fffd0dfe7a0, dpy=0x7fffd0120000, surface=0x7fffd01dc000) at /home/komat/tmp676-trunk-gtk3/src-wayland/gfx/gl/GLLibraryEGL.h:227 #7 0x00007fffeba1fc9b in mozilla::gl::GLContextEGL::SwapBuffers() (this=0x7fffcd261000) at /home/komat/tmp676-trunk-gtk3/src-wayland/gfx/gl/GLContextProviderEGL.cpp:506 #8 0x00007fffebb08d46 in mozilla::layers::CompositorOGL::EndFrame() (this=0x7ffff78bde70) at /home/komat/tmp676-trunk-gtk3/src-wayland/gfx/layers/opengl/CompositorOGL.cpp:1840 #9 0x00007fffebcde602 in mozilla::layers::LayerManagerComposite::Render(mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&) (this=0x7fffcd2a8350, aInvalidRegion=..., aOpaqueRegion=...) at /home/komat/tmp676-trunk-gtk3/src-wayland/gfx/layers/composite/LayerManagerComposite.cpp:1007 #10 0x00007fffebcdd6c3 in mozilla::layers::LayerManagerComposite::UpdateAndRender() (this=0x7fffcd2a8350) at /home/komat/tmp676-trunk-gtk3/src-wayland/gfx/layers/composite/LayerManagerComposite.cpp:544 #11 0x00007fffebcdd232 in mozilla::layers::LayerManagerComposite::EndTransaction(mozilla::TimeStamp const&, mozilla::layers::LayerManager::EndTransactionFlags) (this=0x7fffcd2a8350, aTimeStamp=..., aFlags=mozilla::layers::LayerManager::END_DEFAULT) at /home/komat/tmp676-trunk-gtk3/src-wayland/gfx/layers/composite/LayerManagerComposite.cpp:465 #12 0x00007fffebd0c140 in mozilla::layers::CompositorBridgeParent::CompositeToTarget(mozilla::gfx::DrawTarget*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const*) (this=0x7fffd174cc00, aTarget=0x0, aRect=0x0) at /home/komat/tmp676-trunk-gtk3/src-wayland/gfx/layers/ipc/CompositorBridgeParent.cpp:1105
Assignee | ||
Updated•5 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Updated•5 years ago
|
Assignee: nobody → stransky
Assignee | ||
Comment 3•5 years ago
|
||
dri2_wl_swap_buffers_with_damage() waits in frame throttling - we had this issue before and set SwapInterval to 0 was a workaround for it. I need to find the related info but AFAIK it's a bug in our wl_surface handling code.
Assignee | ||
Comment 4•5 years ago
|
||
It's documented at https://bugs.freedesktop.org/show_bug.cgi?id=106753
Assignee | ||
Comment 5•5 years ago
|
||
https://bugs.freedesktop.org/show_bug.cgi?id=106753#c6 is the resolution here - I'll investigate what changed because Firefox 63 starts fine but latest trunk fails.
Assignee | ||
Updated•5 years ago
|
Priority: P3 → P2
Summary: [Wayland] Opengl/Webrender hangs on "Attempting load of libEGL.so" → [Wayland] Opengl/Webrender hangs in eglSwapBuffers()
Assignee | ||
Comment 6•5 years ago
|
||
The frame callback we use to check the parent surface commit is not enough. We need to listen frame callback on the parent surface as we don't have access to "committed" signal which is used by GdkWaylandWindow internally.
Assignee | ||
Comment 7•5 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=2a64808c65283ccd5181c99fa2b728a5cca86695
Assignee | ||
Comment 8•5 years ago
|
||
Use frame callback to determine if we can draw to wl_surface owned by GtkWidget and use it as a base for EGL Window.
Assignee | ||
Updated•5 years ago
|
Keywords: checkin-needed
Pushed by ebalazs@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c6467f04bcd9 [Wayland/OpenGL] Don't draw to wl_surface owned by GtkWidget (mozcontainer) until it's commited, r=jhorak
Keywords: checkin-needed
Comment 10•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/c6467f04bcd9
Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox65:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
Comment 11•5 years ago
|
||
I can see an improvement, a window is drawn but it's empty and transparent (just the title bar and frame are visible). Is it a known other bug or should I open one? (fresh profile, just enabled gfx.webrender.all)
Assignee | ||
Comment 12•5 years ago
|
||
(In reply to Francois Guerraz from comment #11) > I can see an improvement, a window is drawn but it's empty and transparent > (just the title bar and frame are visible). Is it a known other bug or > should I open one? > > (fresh profile, just enabled gfx.webrender.all) Please file a new one.
You need to log in
before you can comment on or make changes to this bug.
Description
•