Closed Bug 1489902 Opened 5 years ago Closed 4 years ago
[Wayland] Opengl/Webrender hangs in egl
Bug 1489902 - [Wayland/OpenGL] Don't draw to wl_surface owned by GtkWidget (mozcontainer) until it's commited, r=jhorak
47 bytes, text/x-phabricator-request
|Details | Review|
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
Component: Untriaged → Graphics
OS: Unspecified → Linux
Product: Firefox → Core
This is got solved for me on recent versions of nightly (flatpak 64) Still see it in fedora 29, firefox-wayland 62, though.
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
It's documented at https://bugs.freedesktop.org/show_bug.cgi?id=106753
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.
Priority: P3 → P2
Summary: [Wayland] Opengl/Webrender hangs on "Attempting load of libEGL.so" → [Wayland] Opengl/Webrender hangs in eglSwapBuffers()
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.
Use frame callback to determine if we can draw to wl_surface owned by GtkWidget and use it as a base for EGL Window.
Pushed by firstname.lastname@example.org: 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
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)
(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.