1514156 - [Wayland] gfx.webrender.all on Wayland displays an empty window with GDK_BACKEND=wayland

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect, P3)

Description

[Francois Guerraz]

Attachment: Screenshot from 2018-12-14 10-17-57.png

With build id 20181213224257 on Linux 4.19.9, intel graphics, Gnome 3.30.2.

Webrender works very well on XWayland but not on the native Wayland build (launched with GDK_BACKEND=wayland).

Setting layers.acceleration.force-enabled to true works well, OpenGL rendering is enabled and smooth but gfx.webrender.all (alone or in combination) result on a transparent / empty window to be drawn.
Funny enough, the controls still work, I can see the cursor changing shape when hovering the address bar for example and other overlays are drawn correctly (see attachement).

Comment 1

[Francois Guerraz]

Interestingly, it seems like the first launch after an update is always successful, but all subsequent launches result in empty windows.

Comment 2

[Ryan Hunt [:rhunt] (on leave until early May)]

(In reply to Francois Guerraz from comment #1)
> Interestingly, it seems like the first launch after an update is always
> successful, but all subsequent launches result in empty windows.

Sounds possibly related to shader caching, as I think we invalidate it during updates?

Linux or Wayland isn't in our MVP, so marking this P3.

Comment 3

[Martin Stránský [:stransky] (ni? me)]

I think it's a duplicate of Bug 1485616 - can you please check latest nightly?

Comment 4

[Robert Mader [:rmader]]

I also see this quite exactly as described (flatpak nightly from today, 17.12.).
And I can also confirm that under rare circumstances things work fine

fedora 29, intel skylake, gnome git-master

Comment 5

[Martin Stránský [:stransky] (ni? me)]

Flatpak may carry other issues so it's better to test directly Mozilla binaries. You just need to download the tarball and run as "GDB_BACKEND=wayland ./firefox".

Comment 6

[Martin Stránský [:stransky] (ni? me)]

(In reply to Martin Stránský [:stransky] from comment #5)
> Flatpak may carry other issues so it's better to test directly Mozilla
> binaries. You just need to download the tarball and run as
> "GDB_BACKEND=wayland ./firefox".

Sorry, I mean GDK_BACKEND=wayland of course :)

Comment 7

[Martin Stránský [:stransky] (ni? me)]

Yes, I can see that with gfx.webrender.all=true now. It's more reproducible on optimized builds, I used debug builds which almost work.

Comment 8

[Martin Stránský [:stransky] (ni? me)]

I see "Initializing context 0x7f803c98ecf0 surface (nil) on display 0x7f8044a94800" which can be the problem here.

Comment 9

[Martin Stránský [:stransky] (ni? me)]

[Parent 2716, Main Thread] WARNING: nsWindow::GetNativeData(): NS_NATIVE_SHAREABLE_WINDOW is not handled on Wayland!: file /home/komat/tmp676-trunk-gtk3/src-wayland/widget/gtk/nsWindow.cpp, line 1561

Can be also related.

Comment 10

[Martin Stránský [:stransky] (ni? me)]

This is really a variant of Bug 1485616 where we wait until mozcontainer is mapped and mContainer->ready_to_draw flag is set. I don't know if that's possible at WebRender to wait until we have complete widget to draw into. A variant may be to create a dummy wl_surface/wl_egl_window if it's even possible.

Comment 11

[Martin Stránský [:stransky] (ni? me)]

The check at widget level code is performed here:

https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18794ee8257afe99/widget/gtk/nsWindow.cpp#2111

we need something similar to check before we create EGL GLContext for the nsWindow.

Comment 12

[Peter Bašista]

Attachment: Firefox on Wayland with gfx.webrender.all=true - almost nothing visible except for the webpage suggestions

Comment 13

[Peter Bašista]

Attachment: Firefox on Wayland with gfx.webrender.all=true - quit dialog

Comment 14

[Martin Stránský [:stransky] (ni? me)]

Sotaro, is it possible to postpone WebRender rendering / GlContext creation until we have fully mapped widget to draw into?

Comment 15

[Sotaro Ikeda [:sotaro]]

(In reply to Martin Stránský [:stransky] from comment #14)
> Sotaro, is it possible to postpone WebRender rendering / GlContext creation
> until we have fully mapped widget to draw into?

Hmm it seems not easy to postopone GLContext creation. But it seems possible to postpone EGLSurface creation like RenderCompositorANGLE. RenderCompositorANGLE create GLContext by GLContextProviderEGL::CreateHeadless() in CreateGLContextANGLE() and EGLSurface is created later separately in RenderCompositorANGLE::ResizeBufferIfNeeded().

Comment 16

[Viktor Jägersküpper]

I think that bug 1507770 is a duplicate, I could reproduce it reliably by booting with the parameter "maxcpus=1". Please confirm.

Comment 17

[Viktor Jägersküpper]

Correction: I could *not* reproduce it reliably by booting with the parameter "maxcpus=1".

Comment 18

[Francois Guerraz]

In my case the bug is reproducible all the same whether I boot with maxcpus=1 or launch firefox with "taskset 0x1".

Comment 19

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro out of office 28/Dec - 3/Jan] from comment #15)
> (In reply to Martin Stránský [:stransky] from comment #14)
> > Sotaro, is it possible to postpone WebRender rendering / GlContext creation
> > until we have fully mapped widget to draw into?
> 
> Hmm it seems not easy to postopone GLContext creation. But it seems possible
> to postpone EGLSurface creation like RenderCompositorANGLE.
> RenderCompositorANGLE create GLContext by
> GLContextProviderEGL::CreateHeadless() in CreateGLContextANGLE() and
> EGLSurface is created later separately in
> RenderCompositorANGLE::ResizeBufferIfNeeded().

I checked that EGLSurface was not created by GLContextEGL.

Comment 20

[Sotaro Ikeda [:sotaro]]

Attachment: wip patch - Add RenderCompositorEGL for wayland

Comment 21

[Sotaro Ikeda [:sotaro]]

attachment 9033237 [details] [diff] [review] is still wip patch, but it address the problem for me, though GLContextProviderEGL::CreateHeadless() did not work.

Comment 22

[Francois Guerraz]

I would have loved to try the patch but it doesn't apply cleanly on master and doesn't compile if I try to resolve the conflicts

Comment 23

[Sotaro Ikeda [:sotaro]]

Attachment: wip patch - Add RenderCompositorEGL for wayland

Bebased. I confirmed the build locally with latest m-c.

Comment 24

[Francois Guerraz]

Comment on attachment 9034351 [details] [diff] [review]
wip patch - Add RenderCompositorEGL for wayland

Review of attachment 9034351 [details] [diff] [review]:
-----------------------------------------------------------------

Works for me.

Comment 25

[Sotaro Ikeda [:sotaro]]

Thanks for the confirmation!

Comment 26

[Jan Beich]

Comment on attachment 9034351 [details] [diff] [review]
wip patch - Add RenderCompositorEGL for wayland

Review of attachment 9034351 [details] [diff] [review]:
-----------------------------------------------------------------

Breaks build if gtk3 was built with --disable-wayland-backend i.e., the only way to disable Wayland support at build-time after bug 1501218.

In file included from objdir/widget/gtk/Unified_cpp_widget_gtk0.cpp:11:
widget/gtk/CompositorWidgetParent.cpp:45:3: error: use of undeclared identifier
      'RequestsUpdatingEGLSurface'; did you mean 'RecvRequestsUpdatingEGLSurface'?
  RequestsUpdatingEGLSurface();
  ^~~~~~~~~~~~~~~~~~~~~~~~~~
  RecvRequestsUpdatingEGLSurface
widget/gtk/CompositorWidgetParent.cpp:43:49: note: 'RecvRequestsUpdatingEGLSurface' declared here
mozilla::ipc::IPCResult CompositorWidgetParent::RecvRequestsUpdatingEGLSurface()
                                                ^
In file included from objdir/widget/gtk/Unified_cpp_widget_gtk0.cpp:2:
In file included from widget/gtk/CompositorWidgetChild.cpp:6:
In file included from widget/gtk/CompositorWidgetChild.h:9:
widget/gtk/GtkCompositorWidget.h:78:8: error: private field 'mWaylandRequestsUpdatingEGLSurface' is
      not used [-Werror,-Wunused-private-field]
  bool mWaylandRequestsUpdatingEGLSurface;
       ^
2 errors generated.

::: gfx/webrender_bindings/RenderCompositor.cpp
@@ +30,5 @@
>      return RenderCompositorANGLE::Create(std::move(aWidget));
>    }
>  #endif
> +
> +#ifdef MOZ_WIDGET_GTK

Did you mean #ifdef MOZ_WAYLAND instead?

Comment 27

[Val Packett]

Also there's a crashing bug here, it tries to get_wl_egl_window when it shouldn't (?). Happens when e.g. opening webextension popovers, but I think I've seen it with ordinary windows too.

* thread #1, name = 'Renderer', stop reason = signal SIGSEGV
  * frame #0: 0x00000008013b99ca libc.so.7`__sys_thr_kill at thr_kill.S:3
    frame #1: 0x00000008013b9364 libc.so.7`__raise(s=11) at raise.c:52:10
    frame #2: 0x0000000807efff42 libxul.so`nsProfileLock::FatalSignalHandler(signo=11, info=0x00007fffde630330, context=<unavailable>) at nsProfileLock.cpp:165:7
    frame #3: 0x000000080864ba51 libxul.so`WasmTrapHandler(signum=11, info=0x00007fffde630330, context=0x00007fffde62ffc0) at WasmSignalHandlers.cpp:928:5
    frame #4: 0x00000008011e643e libthr.so.3`handle_signal(actp=0x00007fffde62ff40, sig=11, info=0x00007fffde630330, ucp=0x00007fffde62ffc0) at thr_sig.c:246:3
    frame #5: 0x00000008011e59f2 libthr.so.3`thr_sighandler(sig=11, info=0x00007fffde630330, _ucp=0x00007fffde62ffc0) at thr_sig.c:191:2
    frame #6: 0x00007fffffffe003
    frame #7: 0x00000008070547f3 libxul.so`moz_container_get_wl_surface(container=<unavailable>) at mozcontainer.cpp:509:40
    frame #8: 0x00000008070549ff libxul.so`moz_container_get_wl_egl_window(container=0x000000080e099d10) at mozcontainer.cpp:539:27
    frame #9: 0x00000008070309a9 libxul.so`nsWindow::GetNativeData(this=<unavailable>, aDataType=<unavailable>) at nsWindow.cpp:1587:30
    frame #10: 0x0000000805a3fa09 libxul.so`mozilla::gl::GLContextEGL::CreateEGLSurfaceForCompositorWidget(aCompositorWidget=0x0000000824a74fc0, aForceAccelerated=<unavailable>) at GLContextProviderEGL.cpp:310:32
    frame #11: 0x0000000805c97c9c libxul.so`mozilla::wr::RenderCompositorEGL::CreateEGLSurface(aWidget=<unavailable>) at RenderCompositorEGL.cpp:64:13
    frame #12: 0x0000000805c97f89 libxul.so`mozilla::wr::RenderCompositorEGL::BeginFrame(this=0x000000081f3c0b90) at RenderCompositorEGL.cpp:85:21
    frame #13: 0x0000000805c9e0d1 libxul.so`mozilla::wr::RendererOGL::UpdateAndRender(this=0x0000000829a00080, aReadbackSize=0x00007fffde630ca0, aReadbackBuffer=0x00007fffde630c88, aHadSlowFrame=false, aOutStats=0x00007fffde630b80) at RendererOGL.cpp:113:21
    frame #14: 0x0000000805c9d8a9 libxul.so`mozilla::wr::RenderThread::UpdateAndRender(this=<unavailable>, aWindowId=<unavailable>, aStartId=0x00007fffde630c78, aStartTime=0x00007fffde630c80, aRender=<unavailable>, aReadbackSize=0x00007fffde630ca0, aReadbackBuffer=0x00007fffde630c88, aHadSlowFrame=<unavailable>) at RenderThread.cpp:369:26
    frame #15: 0x0000000805c9d730 libxul.so`mozilla::wr::RenderThread::HandleFrame(this=<unavailable>, aWindowId=<unavailable>, aRender=true) at RenderThread.cpp:262:3
    frame #16: 0x0000000805ca509f libxul.so`mozilla::detail::RunnableMethodImpl<mozilla::wr::RenderThread*, void (mozilla::wr::RenderThread::*)(mozilla::wr::WrWindowId, bool), true, (mozilla::RunnableKind)0, mozilla::wr::WrWindowId, bool>::Run() [inlined] decltype(o=<unavailable>, m=<unavailable>, args=<unavailable>).*fp0(Get<0ul>(fp1).PassAsParameter(), Get<1ul>(fp1).PassAsParameter())) mozilla::detail::RunnableMethodArguments<mozilla::wr::WrWindowId, bool>::applyImpl<mozilla::wr::RenderThread, void (mozilla::wr::RenderThread::*)(mozilla::wr::WrWindowId, bool), StoreCopyPassByConstLRef<mozilla::wr::WrWindowId>, StoreCopyPassByConstLRef<bool>, 0ul, 1ul>(mozilla::wr::RenderThread*, void (mozilla::wr::RenderThread::*)(mozilla::wr::WrWindowId, bool), mozilla::Tuple<StoreCopyPassByConstLRef<mozilla::wr::WrWindowId>, StoreCopyPassByConstLRef<bool> >&, std::__1::integer_sequence<unsigned long, 0ul, 1ul>) at nsThreadUtils.h:1119:12
    frame #17: 0x0000000805ca5080 libxul.so`mozilla::detail::RunnableMethodImpl<mozilla::wr::RenderThread*, void (mozilla::wr::RenderThread::*)(mozilla::wr::WrWindowId, bool), true, (mozilla::RunnableKind)0, mozilla::wr::WrWindowId, bool>::Run() [inlined] _ZN7mozilla6detail23RunnableMethodArgumentsIJNS_2wr10WrWindowIdEbEE5applyINS2_12RenderThreadEMS6_FvS3_bEEEDTcl9applyImplfp_fp0_dtdefpT10mArgumentstlNSt3__116integer_sequenceImJLm0ELm1EEEEEEEPT_T0_(this=<unavailable>, o=<unavailable>, m=<unavailable>) at nsThreadUtils.h:1125
    frame #18: 0x0000000805ca5080 libxul.so`mozilla::detail::RunnableMethodImpl<mozilla::wr::RenderThread*, void (mozilla::wr::RenderThread::*)(mozilla::wr::WrWindowId, bool), true, (mozilla::RunnableKind)0, mozilla::wr::WrWindowId, bool>::Run(this=<unavailable>) at nsThreadUtils.h:1171

Comment 28

[Sotaro Ikeda [:sotaro]]

(In reply to greg from comment #27)

Also there's a crashing bug here, it tries to get_wl_egl_window when it shouldn't (?). Happens when e.g. opening webextension popovers, but I think I've seen it with ordinary windows too.

Thanks for the report! I created Bug 1525213 for it.

Comment 29

[Sotaro Ikeda [:sotaro]]

(In reply to Jan Beich from comment #26)

Comment on attachment 9034351 [details] [diff] [review]
wip patch - Add RenderCompositorEGL for wayland

Review of attachment 9034351 [details] [diff] [review]:

Breaks build if gtk3 was built with --disable-wayland-backend i.e., the only
way to disable Wayland support at build-time after bug 1501218.

::: gfx/webrender_bindings/RenderCompositor.cpp
@@ +30,5 @@

 return RenderCompositorANGLE::Create(std::move(aWidget));

}
#endif
+
+#ifdef MOZ_WIDGET_GTK

Did you mean #ifdef MOZ_WAYLAND instead?

Yes.

Thank you for the notification.

Comment 30

[Sotaro Ikeda [:sotaro]]

Attachment: wip patch - Add RenderCompositorEGL for wayland

Fixed build failure during disabling wayland.

Comment 31

[Sotaro Ikeda [:sotaro]]

Attachment: wip patch - Add RenderCompositorEGL for wayland

Comment 32

[Sotaro Ikeda [:sotaro]]

Attachment: Bug 1514156 - Add GLContextEGL::CreateEGLSurfaceForCompositorWidget() for Wayland

Comment 33

[Sotaro Ikeda [:sotaro]]

Attachment: Bug 1514156 - Add GLContextEGL::CreateEGLSurfaceForCompositorWidget() for Wayland

When GDK_BACKEND is wayland, widget is not fully mapped during creating CompositorSession. During CompositorSession creation, GLContextProviderEGL::CreateForCompositorWidget() creates GLContextEGL, but we could not create valid EGLSurface. We could create valid EGLSurface when widget is fully mapped. CreateEGLSurfaceForCompositorWidget() is used for creating valid EGLSurface after widget is fully mapped.

https://phabricator.services.mozilla.com/D18654

Comment 34

[Sotaro Ikeda [:sotaro]]

Attachment: wip patch - Add RenderCompositorEGL for wayland

Comment 35

[Sotaro Ikeda [:sotaro]]

Attachment: Bug 1514156 - Add RenderCompositorEGL for wayland

Comment 36

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/d97a89ada9e6
Add GLContextEGL::CreateEGLSurfaceForCompositorWidget() for Wayland r=jgilbert
https://hg.mozilla.org/integration/mozilla-inbound/rev/19ccde31eaaa
Add RenderCompositorEGL for wayland r=nical

Comment 37

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/d97a89ada9e6
https://hg.mozilla.org/mozilla-central/rev/19ccde31eaaa

Comment 38

[Francois Guerraz]

I don't think this is completely fixed, extensions/addons surfaces are still transparent (tried µBlock0, bitwarden & feedbro).

Comment 40

[Sotaro Ikeda [:sotaro]]

(In reply to Francois Guerraz from comment #38)

I don't think this is completely fixed, extensions/addons surfaces are still transparent (tried µBlock0, bitwarden & feedbro).

Created Bug 1527804 for it.

Comment 41

[Liz Henry (:lizzard) (relman/hg->git project)]

I think this may be best to let ride with 67.

Comment 42

[Laurențiu Nicola]

This still happens for me on about 30% of runs (Gnome Wayland, WebRender, session restore). A window is created, but it's transparent or otherwise invisible.

Comment 43

[Laurențiu Nicola]

Never mind, that could be bug 1532024.