Description of problem: It appears that with GNOME 45, "org.gnome.mutter.experimental-features/scale-monitor-framebuffer" is now enabled by default via GSettings. I don't think this is a good idea - even with integer scaling (i.e. 200%), with this option enabled, I get very blurry xwayland windows (I do not understand why). Turning the option off and setting scaling to 200% gives me criply rendered XWayland windows. This also results in weird new behaviour (i.e. the default scaling factor is different than on Fedora 38), for example, I now get 250% scaling on my laptop, which I certainly don't want. Scaling by fractions *might* be OK in sessions that are wayland-only (like the GDM greeter), but for user sessions, this seems premature (especially with no way to revert to the "old" scaling behaviour in the UI). Version-Release number of selected component (if applicable): mutter-45.0-2.fc39.x86_64 How reproducible: Always (when using better than LoDPI screens.) Steps to Reproduce: 1. Log into GNOME 45 2. Open a Window that uses XWayland (like Visual Studio Code) 3. See blurry fonts even with integer scaling (200%) 4. Remove "scale-monitor-framebuffer" from enabled experimental features 5. Log out and back in 6. Open a Window that uses XWayland 7. See crisp fonts again (with the *same* scaling factor of 200%) Actual results: Experimental feature enabled by default, leading to poor rendering of common applications, and weird default scaling behaviour (like 125% or 250%). Expected results: Experimental feature should likely not be enabled by default. Additional info: N/A
This was an intentional change, but I think it may not have been clearly understood that it would cause the fuzziness issues in certain apps to affect even *integer* scaling factors. I certainly wasn't aware of that when we were discussing it.
So, as far as I can tell, this change has two negative effects: 1. Integer scaling (100%, 200%, 300%) has regressed, and now renders XWayland windows *much* worse. 2. XWayland windows only see a downscaled frame buffer (i.e. 1080p on a 4K screen with 200% scaling), making it impossible to play games at the native window resolution. To me, this looks like the new "fractional" scaling mode enabled by the "scale-monitor-framebuffer" setting renders windows to a scaled framebuffer, and upscales to the full resolution. This might be the reason why XWayland windows that support "X11-native" integer scaling look so much worse than before, and why games only see a downscaled monitor size - they are getting upscaled in software from rendering at 1x. The first one makes many popular IDEs (VS Code, Jetbrains, ...) unusable due to the regression in text rendering quality, and the second one makes fullscreen applications (like games) look much worse (i.e. not being able to use the native screen resolution *and* then getting upscaled in software).
There's some good background and explanations at https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1833 , which I'd seen referenced but hadn't actually read through before. It explains that there's kind of a lot going on here. More than I appreciated before, `scale-monitor-framebuffer` is a *different* mode with different tradeoffs, not just a kinda 'flip on fractional levels and everything else stays the same' switch. If I'd understood this better before we went ahead and made it default I think I'd have preferred the idea of waiting till that UI is figured out and implemented.
Yeah ... I'm afraid that this tradeoff might be worthwhile if you only consider GTK apps and other applications that support native wayland rendering / scaling, but it would make Fedora unsuitable for a large amount of users (both developers, and people who play games) by default, especially if there's no obvious way to revert to the previous behaviour. I'm inclined to propose this as a blocker bug for F39 Final, it looks like this criterion might cover it: https://fedoraproject.org/wiki/Fedora_39_Final_Release_Criteria#Window_manager_functionality "games must be displayed correctly" might be appropriate if it's impossible to configure the game to render at "native" screen resolution? If that's not enough, I'll likely propose this bug as a FESCo exception.
> If I'd understood this better before we went ahead and made it default I think I'd have preferred the idea of waiting till that UI is figured out and implemented. This is also what I suggested in the issue about turning this on by default.
Yep, that's why I said "preferred the idea" - I remembered that someone suggested it!
We discussed the proposed UI at last week's Workstation Working Group meeting and we're quite skeptical about adding it to Fedora Workstation. An on/off switch to choose between two different broken behaviors -- broken scaling vs. broken legacy applications -- is not user-friendly. Please discuss the proposed UI with GNOME design team, but expect it to be rejected. I'll emphasize that we knew this change would make XWayland applications blurry, but approved it anyway because no superior solution is planned, i.e. waiting will not change the situation. If somebody were working on a way to do fractional scaling without blurry XWayland applications, that would be lovely and it would make sense to wait for that. But it really looks like that's not going to happen. It's a *very* frustrating choice, but we chose to prioritize modern hardware rather than legacy applications, and I'm confident that's the correct choice for Fedora Workstation. So I respectfully request this not be approved as a blocker bug. (It's time for XWayland applications to move on anyway; anything that supports GTK 3 or Qt 5 should be using Wayland, anything based on Chromium should turn on the Wayland support, and most other applications are probably *really* old.)
It's not that I haven't tried using VS Code natively on Wayland (by passing the necessary flags for it to use the Wayland Ozone backend). The rendering looked correct (if it didn't crash and burn immediately, which seemed to happen randomly), but there were other problems (like apparent mouse cursor location not matching actual pointer location, making it very frustrating to hit small menu elements). I understand that this is a frustrating choice, but I still think it's the wrong one, until there's a better solution for XWayland clients that *do* support X11-native scaling (or for basically *all* games). https://pagure.io/fesco/issue/3075
A recent case I happened to see where something turned *off* Wayland support again after trying turning it on: https://github.com/flathub/com.slack.Slack/pull/213 note the list of "fixed" issues.
We've agreed to defer this change to Fedora 40 so I'm adjusting the affected version accordingly.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle. Changing version to 40.