The Wayland core protocol does not support fractional scaling, so it's implemented by downscaling integer-scaled pixmaps, with a scaling algorithm that makes things look blurry. It seems like there's room for using a better scaling algorithm so things don't look so blurry. It's hard for me to personally reproduce this since I have a 4K screen, but I've seen screenshots from users with lower-resolution screens that makes it seem really bad.
And yes, I know that some blurriness is inevitable, there being no such thing as fractional pixels and all that. Still, it seems like there could be alternative downsampling algorithms that would do a better job than the current one.
The issue isn't entirely fractional scaling and half pixels. Even at 200% there are a number of issues with the scaling option. Firstly there are odd minor issues like the mouse cursor looks incredibly blocky. There is a separate option for setting the cursor resolution and zooming the pixels doesn't pick the larger image. UI elements are scaled, some icons look OK, some look blown up. Fonts in certain UI elements aren't scaled (drop down boxes on wayland). The showstopper for me though, is that I can't view 4k videos or images on my 4k screen. If I view a 3840x2160 image in Firefox with 200% display scaling I have a choice: See 1/4 of it cropped with scrollbars or view it scaled to 1080p. I cannot see the whole image untouched. If I view a 4k video it gets scaled down to 1080p if I have 200% scaling. The scaling option isn't much better than just running my screen at a 1080p resolution. Text and some icons are better but nothing else. It might be possible for individual applications to support scaling properly but at the moment Firefox, VLC nor mpv do this, and enabling scaling shouldn't really limit the user's choice of applications. I have a choice of either reading text on the screen at a legible size or being able to view a 4k video on a 4k screen. This forced choice seems to be by design. The whole screen scaling approach seems like the wrong way to go to me as it introduces its own set of problems and limitations on the user. What's frustrating is that in Xorg, setting DPI works near perfectly. The UI is scaled, icons are scaled, context menus are scaled and I can view images and videos without them being scaled unless I want them to. The only issue is that some windows start fairly small. But at least they can be resized easily. Even when you reintroduce this option on Wayland, it wasn't ever working properly there. Fonts are scaled but padding around text, borders and other UI elements are completely ignored. Would it be possible to copy over the Xorg code that scales the UI and Icons based on DPI from Xorg to Wayland? For example, try setting font DPI to 192 and launching Rhythmbox or Dolphin. On Xorg looks great, on wayland everything is crashed together because the paddings around text and icons are not increased relative to the text size. So at the moment, as much as I'd like to use Wayland I'm stuck on Xorg because neither DPI or scaling work without issues.
Those are all true, but this bug report isn't supposed to be a "general gripes with hidpi" thing. It's about one thing: blurry downscaled pixmaps when using a fractional scale factor on Wayland. Could you file separate bug reports for those other issues with using the Qt scaling system? Thanks!
https://www.reddit.com/r/kde/comments/lficfe/wayland_fractional_scaling_may_be_sort_of_a/
Why KDE/Wayland cannot have scaling without lowering resolution like in KDE/X11? Scaling on X11 is mostly works and similar to windows.
Because of what I said in the original description: > The Wayland core protocol does not support fractional scaling This need to be fixed in Wayland itself. This bug report is about improving the appearance of the downscaled pixmaps--not about adding fractional scaling to the core Wayland protocol itself.
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/34
Yep, that's a good discussion for how to solve the problem optimally upstream.
Lets follow things there.
*** Bug 433810 has been marked as a duplicate of this bug. ***