Window border corruption after changing display scale between 100% and 200% in Xorg

Bug #1924689 reported by Kai-Chuan Hsieh
46
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Mutter
New
Unknown
OEM Priority Project
New
Undecided
Yao Wei
mutter (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Ubuntu release:
Ubuntu 20.04.2 LTS

Issue description:
When the gnome-initial-setup launched, if user changes the scale 200 -> 400 or 100 -> 200.
There is some garbage on the edge of the window.

The issue is not seen if we login in wayland session.

A video is attached.

Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote :
tags: added: oem-priority originate-from-1918215 somerville
summary: - Can see some garbage at the edge of the Window after changing scale
+ Can see some garbage at the edge of the window after changing scale
description: updated
affects: gnome-initial-setup (Ubuntu) → gnome-shell (Ubuntu)
affects: gnome-shell (Ubuntu) → mutter (Ubuntu)
Changed in mutter (Ubuntu):
importance: Undecided → Low
status: New → Triaged
tags: added: common
tags: removed: common
Changed in oem-priority:
assignee: nobody → Yao Wei (medicalwei)
Revision history for this message
Yao Wei (medicalwei) wrote :

Tried modifying the source code of gnome-initial-setup, found that this issue cannot be reproduced, if the titlebar of the window (gis-assistant) is not set in the main (gis-driver) window.

I think this issue can be worked around in gis-assistant, but the root cause might be either gnome-initial-setup, mutter or libgtk-3

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Yes I think it looks like a mutter bug judging by the video.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Mutter keeps multiple copies of window-related things, moreso on X11 where the server is a separate process with its own idea of how big a window is. That also means a window gets resized in multiple processes at slightly different times. So it's easy to mess up in mutter and get bugs like this (I have done in the past).

Yao Wei (medicalwei)
summary: - Can see some garbage at the edge of the window after changing scale
+ When changing screen scale in X11, gnome-initial-setup's window shadow
+ can be glitched
summary: When changing screen scale in X11, gnome-initial-setup's window shadow
- can be glitched
+ should not be glitched
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Re: When changing screen scale in X11, gnome-initial-setup's window shadow should not be glitched

I suggest trying to find a generic app that upstream (Red Hat) will have as a test case. If you can do that then it should be reported to https://gitlab.gnome.org/GNOME/mutter/issues

Yao Wei (medicalwei)
summary: - When changing screen scale in X11, gnome-initial-setup's window shadow
- should not be glitched
+ When changing screen scale in GNOME Xorg, gnome-initial-setup's window
+ shadow should not be glitched
Revision history for this message
Yao Wei (medicalwei) wrote : Re: When changing screen scale in GNOME Xorg, gnome-initial-setup's window shadow should not be glitched

Reported to upstream with stripped test case: https://gitlab.gnome.org/GNOME/mutter/-/issues/1875

Changed in mutter:
status: Unknown → New
summary: - When changing screen scale in GNOME Xorg, gnome-initial-setup's window
- shadow should not be glitched
+ Top-left window border corruption after increasing display scale from
+ 100% to 200% in Xorg
Revision history for this message
Launchpad Janitor (janitor) wrote : Re: Top-left window border corruption after increasing display scale from 100% to 200% in Xorg

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-initial-setup (Ubuntu):
status: New → Confirmed
Changed in gtk+3.0 (Ubuntu):
status: New → Confirmed
no longer affects: gnome-initial-setup (Ubuntu)
no longer affects: gtk+3.0 (Ubuntu)
tags: added: lunar
tags: added: focal
Changed in mutter (Ubuntu):
importance: Low → Medium
tags: added: xrandr-scaling
summary: - Top-left window border corruption after increasing display scale from
- 100% to 200% in Xorg
+ Window border corruption after changing display scale between 100% and
+ 200% in Xorg
Revision history for this message
herrsaalfeld (herrsaalfeld) wrote :

This bug is not limited to changing the scale from lower to higher and is not limited to shadows displaying garbage. It also occurs:

* when changing the scale from higher to lower
* infrequently when new windows or dialogs are created, particularly snap apps like nautilus or gnome-text-editor or modal dialogs such as e.g. evolution

Other effects in addition to shadows displaying garbage are:

* the window not capturing mouse events correctly, other windows below the garbage window capture the events
* the window not being able to capture focus, i.e. come to the front of other windows

The situation can be 'fixed' by maximizing + unmaximizing the window, users can TAB-select the window if it cannot be reached with the mouse.

(Summary from my duplicate bug report https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/2023209)

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Yes sometimes we need to oversimplify bug descriptions to ensure people can find and understand them.

I believe this is a general problem with the underlying X Window and Mutter actor getting out of sync, where one is still rendering (and interpreting input) at the old scale and the other expecting to render at the new scale.

Revision history for this message
herrsaalfeld (herrsaalfeld) wrote :

It's more than 2 years after this bug was filed first. Does this mean that there is no interest in fixing the Ubuntu desktop? Is that even a mutter bug? Triaging was seemingly done under false assumptions about the boundaries of the bug. Any hints why this bug is mainly present in Snap apps?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I agree this is an ugly bug but since it's likely to happen at most once ever (assuming you don't change display scales often), it doesn't qualify for high priority compared to our other work. Still, this is open source and anyone is entitled to try and debug it and offer fixes.

It's not "mainly present in Snap apps". It's been known to occur in other (deb) apps from the beginning.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

> likely to happen at most once ever

Come to think of it, most people changing display scale will never encounter the bug at all. Because most systems will get a Wayland session by default and Wayland is not affected. This bug only affects Xorg sessions. So that means some Nvidia systems, some virtual machines, and not much more.

Revision history for this message
herrsaalfeld (herrsaalfeld) wrote :

1. This bug happens without screen scale changes, e.g. modal appointment reminder windows by Evolution regularly start in this screwed up state.
2. Switching screen scales is pretty normal for a production laptop that goes on and off external monitors, e.g. between working desk and commuter shuttle/ kitchen table. Not an unusual setup.
3. Snap apps *always* end up borked after screen scale changes, other apps sometimes, there is something with the snap apps that could be interesting to investigate, if anybody cared to investigate.
4. Xorg + Nvidia are pretty typical for many production laptops, e.g. for the rare tribe of engineers working with deep learning. Ubuntu is a typical operating system because it aligns well with the servers that are eventually used. This is certainly not everybody but a cool bunch.
5. There are many reasons why Wayland may not be appropriate for a laptop used for work, I found a list online https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277 and my personal thing would be: How to I ever get out of Libre Office (which hangs a lot for simple stuff like copy-pasting a table column) without xkill?
6. I strongly believe that the attitude "this is open source and anyone is entitled to try and debug it and offer fixes" is inappropriate and a weird kind of gate keeping that is toxic to open source projects. Open source is not open source and your expertise is not mine. I am a user of thousands of open source projects and I contribute to and maintain a couple of tens. I am an expert in my domain and I care for the open source projects that I can contribute to. I do not tell users to fix my bugs. I am not an expert in fixing novel window decoration bugs in Ubuntu, this is your domain, please take ownership of your bugs.

Revision history for this message
herrsaalfeld (herrsaalfeld) wrote :

I spent a day on Wayland, and I found that parts of this bug are present on Wayland, though somehow less frequently, I could only trigger them with screen scale changes. Not all apps seem to be affected equally, but I can trigger it reliably with the Signal, Slack, git gui or gitk apps. Signal and Slack are snaps, git gui and gitk are installed via apt. Open the app, change screen scale from 200 to 100 or vice versa, see the mess. Scaling from 200% to 100%, these apps get a defunct window decoration that is out of sync and size with their content, the texture buffer is apparently full of random garbage that fills the holes. The effect is slightly different, depending on whether the app had been started at 100% or 200% screen scale.

Summary of this update: This bug affects both Xorg and Wayland with Ubuntu's Gnome standard distribution.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Thanks. I find it surprising there is a similar issue on Wayland. Maybe it is just a similar issue with a different root cause. Can you attach a screenshot or photo of the Wayland issue? Still, it might need a separate bug.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.