GNOME Bugzilla – Bug 775093
Missing (partial) window redraw when returning to a window on a different workspace (gnome-shell)
Last modified: 2018-05-02 17:48:09 UTC
I keep running into the issue that (partial) redraws of windows which are on a different workspace are lost when switching back to that window. I could only observe this with gnome-terminal, but suspect it is a more general issue. General setup: * ssh+screen+irssi in one gnome-terminal window * further terminals on other workspaces (in this case I had one further gnome-terminal on the same workspace) General steps which lead to the bug: 1. work in gnome-terminal on a different workspace from irssi 2. get notification about a new highlight (I have a script which does this through ssh) 3. switch to the gnome-terminal window using ctrl+^, switching workspace The result: * gnome-terminal technically has the keyboard focus * I can type into irssi, and text appears normally * gnome-terminal window is styled as if it was not selected (I think it can happen that the title text is redrawn later, but the rest of the window frame is not) * The message I got the notification for is not displayed; typing into irssi doesn't make it appear as that is only a partial expose of the modified line * Obviously things will be correct if e.g. a new message arrives or a redraw happens for another reason. This is all without mouse interaction. This happens on Debian sid; GNOME shell 3.22.2, GTK+ 3.22.4, libmutter 3.22.2. Please reassign if this is more likely a shell/mutter/gnome-terminal issue.
Hmm, so it just happened again, but this time it was: 1. Have browser open 2. notification happen 3. close browser, other terminal window is selected 4. switch to correct window on different workspace using alt+^
Hrm, I am pretty sure I am also seeing this issue in conjunction with gnome-terminal on Fedora 25. Though I still have no sane way of reproducing it :-/
So, I have learned that removing gdk_window_process_updates in VTE almost solves this bug (but not entirely!). Patrick was hitting it a lot in newer gnome-shell versions (with maximize/unmaximize animation). Removing the call to gdk_window_process_udpates fixes it in most cases, but the bug can still be triggered when maximizing/unmaximizing quickly in a row. So it seems like: * Triggering might require a committed frame to be pending * It can be triggered by updates happening outside of the frame clock (which doesn't necessarily mean a frame is pending, just that we render multiple times into the staging frame) * It *might* be related to back-filling from an already committed buffer (i.e. back-filling areas that were actually updated) * Further partial updates will *not* cause the area to appear * mutter will get multiple attach + damage rectangles (attach for the same surface, damage needs to be aggregated) Unfortunately, I have read over the back-filling code and I cannot think of any corner case where it goes wrong. I am not that sure about the mutter side though.
Reminds me of bug 782381 with Qt somehow, where multiple damage rectangles would be repainted while not damaged. iirc, the outcome of the discussion on irc (#wayland) was that the buffer should be consistent even outside the damaged areas, thus pointing to a Qt issue rather than mutter.
Logs here: https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=wayland&highlight_names=&date=2017-05-11
(In reply to Olivier Fourdan from comment #4) > Reminds me of bug 782381 with Qt somehow, where multiple damage rectangles > would be repainted while not damaged. > > iirc, the outcome of the discussion on irc (#wayland) was that the buffer > should be consistent even outside the damaged areas, thus pointing to a Qt > issue rather than mutter. Yes, that's very true. Any part of your window can be repainted at any time: because it was previously occluded and is now visible, because it's on an overlay and is being constantly repainted, needing to blend with changing translucent windows above, etc etc. Any client which sends buffers which, considered singularly / in their entirety regardless of damage area, display incorrectly, are flat-out broken.
GTK+ *should* always be sending a frame that is correct in its entirety. i.e. it either draws on top of the previously committed buffer (if released by wayland already) or it will back-fill in all parts that were not redrawn from it. Only exception is after a resize where the GDK wayland backend will invalidate the entire window thereby a full redraw should happen.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/711.