GTK3 apps connected via XWayland stop repainting after switching virtual desktops in gnome-shell
Affected version
Using Fedora 33 with Gnome 3.38, Wayland session
Gtk is gtk3-3.24.24-1.fc33.x86_64
This is a regression from mutter 3.36.7 to 3.38.
Bug summary
The problem is that with my 2-display setup, switching workspaces away and back causes GTK3 applications that use XWayland not to repaint their windows ever again.
Example: gvim (which doesn't support Wayland) or GDK_BACKEND=x11 gedit
display setup:
- laptop one on the left, with refresh 60,02 Hz, secondary
- external one on the right, with refresh 60,00 Hz, primary
Steps to reproduce
- log into gnome-shell wayland session
- start gvim
- Super+PgDown
- Super+PgUp
What happened
- gvim window never repaints, but does still react to button clicks
doesn't reproduce 100% of the time but at least 50%...
What did you expect to happen
repaint windows
Relevant logs, screenshots, screencasts etc.
did some bisecting; by using the gnome-shell from jhbuild, everything else from Fedora 33:
systemd edit --user --full org.gnome.Shell@wayland.service
ExecStart=/home/test/.local/bin/jhbuild run gnome-shell
(btw, none of the documented ways to launch a wayland session from jhbuild worked for me)
gnome-shell was at commit 86b5a43008aa5afad6bfefe5542f048de226e575
bisect in mutter:
There are only 'skip'ped commits left to test. The first bad commit could be any of: 20becd78 442f34b4 e12ce703 feb8bfa0 59a38fcb d29c8e29 190e285c d77bcb90 a9a9a0d1 f9be6705 aa34f6ad We cannot bisect more!
last good commit was: commit 57a2f7b4 (refs/bisect/good-57a2f7b4)
with the skipped commits, the problem was even worse because windows completely disappeared after virtual desktop switch; the newest of the commits fixed it to the current buggy state.
first skipped/bad commit:
commit a9a9a0d1 (refs/bisect/skip-a9a9a0d1) Author: Jonas Ådahl jadahl@gmail.com Date: Sat May 30 00:27:56 2020 +0200
clutter: Paint views with individual frame clocks
Replace the default master clock with multiple frame clocks, each
driving its own stage view. As each stage view represents one CRTC, this
means we draw each CRTC with its own designated frame clock,
disconnected from all the others.
For example this means we when using the native backend will never need
to wait for one monitor to vsync before painting another, so e.g. having
a 144 Hz monitor next to a 60 Hz monitor, things including both Wayland
and X11 applications and shell UI will be able to render at the
corresponding monitor refresh rate.
This also changes a warning about missed frames when sending
_NETWM_FRAME_TIMINGS messages to a debug log entry, as it's expected
that we'll start missing frames e.g. when a X11 window (via Xwayland) is
exclusively within a stage view that was not painted, while another one
was, still increasing the global frame clock.
Addititonally, this also requires the X11 window actor to schedule
timeouts for _NET_WM_FRAME_DRAWN/_NET_WM_FRAME_TIMINGS event emitting,
if the actor wasn't on any stage views, as now we'll only get the frame
callbacks on actors when they actually were painted, while in the past,
we'd invoke that vfunc when anything was painted.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/903
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285