My kingdom for Wayland fractional scaling that doesn’t make my apps blurry. It makes the feature a complete nonstarter for me.
See the screenshot of my settings: https://imgur.com/a/VQHD5vT
In fact, none of them were blurry 3 years ago.
I'm convinced I don't understand this thing. I feel like it's NOT the compositors job to scale the pixels of an application. That might be a good hack for super high resolution screens with applications that don't know how to handle high DPI but it's an inferior solution. Scaling text at the pixel level is going to be inferior to rendering it at higher resolution to start with.
So how does it work? Do we have per-monitor setting for scale factor, and both the DE and the apps need to follow it for idea behavior? And the compositor scaling the apps is a stopgap? Is that it, or is there more to this?
Under a Wayland compositor, there are basically three types of apps.
1. XWayland apps which cannot use Wayland's scaling protocols, but may be able to use Xft.dpi to scale themselves. Examples include Electron apps when not running on Wayland and later versions of Qt5. These will work without blurriness but they cannot support proper multi-dpi support. The Wayland compositor has no way of detecting whether it actually scales. Some compositors (KDE, Hyprland) let you not scale them, but others (GNOME) will make them super blurry because they are rendered at 96 DPI and stretched to the needed scale. GTK3 notably never supported fractional scaling on X11.
2. Wayland apps which supports integer scaling only. Examples include GTK3, GTK4, Qt5 apps, Mozilla Firefox (minus the experimental fractional scaling feature, which is very buggy). When compositor wants to render at a fractional resolution, the app will render at the nearest integer scale, and the compositor will downsample it. These don't look ideal, but aren't super blurry either, and will work properly with multi-dpi monitors.
3. Wayland apps which properly support fractional scaling via wp-fractional-scale-v1. This is a recent addition to the protocol, so not widely supported yet. The only toolkit that supports it is Qt6, but Chromium (incl. recent Electron apps in Wayland mode) also supports it. Some terminal emulators do too. This results in pixel perfect rendering and looks ideal and works properly with multi-dpi monitors.
Downsampling works well on Macs which have high resolution screens such that you mostly use at least 175% scaling. At lower scales such as 125% (e.g. 1080p 13-14 inch laptops) and 150% (e.g. 1440p 14-16 inch devices), the degradation is fairly obvious if you use smaller fonts. This also breaks subpixel rendering (Macs haven't had it for a long time), which is important for making fonts look good on lower DPI screens. In some ways, Wayland scaling is a regression for KDE because Qt5 had proper fractional scaling for some time under X11, which was not implemented in Wayland as the protocol came out after Qt5 lost support.
Can't X apps just set a window property (XChangeProperty) with their scale factor and have compositor read that?
Especially GTK 3, which was incompatible (by default) with anything that didn't resemble the imagined wayland future, including non RGBA8888 displays or systems with different GL and X11 visuals.
Every X11 app is already composited and scaled by compositor and has top-level X window where it could set any property it wishes.
Also, unless you're running Xsgi, it's not a given that every app is scaled by compositor.
Honestly, the right way was always to not assume any given DPI, and instead have every top-level window be DPI-aware and have the toolkit update that information dynamically.[1] Or optionally go all-in on vector dpi-independent approach.
[1] The only correct way to handle hi-dpi on Win32 GDI, where scaling is broken partly by old GDI assumption that DPI didn't change, and by applications that hardcoded 96 dpi
Yes, you can have a per-monitor scale factor and apps should render at the right scale based on where they are positioned.
Proof: consider a pattern of alternating black and white pixels: 0, 255, 0, 255, 0, 255, etc. This pattern cannot be scaled to a non-integer factor without introducing gray colors (i.e., by blurring-out the pattern). If your app produces this pattern, then fractional scaling will blur your app.
And it's not just text, but UI controls too. It looks like Wayland just renders the lower integer scale factor and then stretches the resulting bitmap image. That's bullshit.
If you can't render fractional factors natively for tech debt reasons then that's the least bad way to do it.
But there apparently is another way that Xorg and Windows uses. I have perfectly crisp (as far as my eyes can tell) UI and text on both systems at 150% scale (27" 4K display).
> for tech debt reasons
I thought Wayland was supposed to fix the tech debt - so now it introduced some that makes bare basic features impossible?
However, Wayland does not prescribe any method for non-integer scaling. Any Wayland WM could choose to do the same thing, and it would be hardware accelerated essentially for free.
Both X11 and Wayland WMs typically don't use this trick, and neither does Windows.
In other words vectors may be scaled with little precision loss, or they may be scaled naively (render to bitmap and then scale the bitmap).
When people complain about desktop apps not scaling they aren't complaining about the odd icon, it's the whole app looking like a smeary mess because it's not using vector based graphics. Fronts, grid lines etc. become blurry.
Also, don't you get the same effect (readable large fonts but alignment changes a bit) when you increase the size of your UI fonts, even without changing overall UI scaling?
Why are people (apparently) so attached to pixel alignments for OS-native GUIs?
This is because the protocol negotiates the size of the underlying buffer. If the client and the compositor agree on the scale, then no scaling of the buffer will happen in the compositor because the client has attached a buffer that is the exact pixel size size of the window on the physical display.
It is up to the client how it implements the case you described. E.g. it could alternate between 1 black and 1 white pixel in the physical buffer or it could sometimes make two adjacent pixels the same color.
Source: I was involved in the design of this protocol and we had example clients that used this exact pattern. Chromium also supports this protocol without any blur.
This is a very odd definition of "no blur".
Having people with no understanding of, or worse no interest in, beautiful UIs making decisions for the display server is a worry.
This is also the definition of blurriness.
I think the screenshot looks fine (other than the weird kerning), but I can see how one person's antialiasing could be other people's blurriness
This is not true in any sense, but it is what some people think when they don't know much about the underlying principles and just see fractional pixels.
A blur would be lowering the frequency of an input signal, anti-aliasing is representing that signal more accurately when quantizing it into discreet values.
Do some animated aliased 3D renders then try to blur it to get the same result as an anti-aliased version.
Look at a checkerboard pattern as it goes into the distance. The pattern eventually converges into grey if it is antialiased because the integral of everything under the pixel is grey as the squares end up smaller than a pixel. Blurring the entire frame gives a much different result.
You cannot scale things to non-integer amounts without incurring some damage.
Blurry/fuzzyness, ringing, screen door effect, etc, you cannot avoid these no matter how smart your scaling algorithm is as long as you're upscaling it to something inbetween 100% and 200%. Nyquist-Shannon is a bitch.
Wayland made a decision way back that non-scaling apps can only be integer scaled to avoid this defect. This was the correct decision, objectively. Unfortunately, people still choose to own monitors that have weird resolutions that do not approximate 96dpi after integer scaling.
Thankfully, 200% dpi screens (ex: 3840x2160 in 24", where 24" are normally 1080p) are starting to become the norm, so someday this problem will go away: you will always be scaling at least 200%, making non-integer scaling artifacts a lot less visible.
Also, I think the parent comment that enriquto replied to might be confused and is merely asking for nearest neighbor scaling. This is not part of Wayland (which is just a protocol), and is managed entirely by the WM being used. Given Wayland is trying to enforce integer scaling, WMs allowing choosing nearest neighbor when integer scaling would be preferable in many cases.
It’s not always a choice unfortunately. I buy displays that are capable of a clean 1x or 2x when I can, but there’s a ton of laptops that still need fractional scaling.
Take my Thinkpad X1 Nano. Great laptop in a lot of ways, including the screen (~500 nits brightness, excellent backlight consistency, color, and contrast, no glare) except that it runs at a resolution that requires 1.5x scaling to be usable.
Looking at replacement candidate laptops, the only ones that have 2x screens that aren’t a downgrade somehow destroy battery life (e.g. 3000x2000 OLED panel in Dragonfly Elite G4, which docks 3-4h of battery). 1x screens in this category for some reason are all kinda crappy with e.g. dim 350 nit backlights that start to struggle in a moderately naturally well-lit room, which is just goofy in a portable machine that’s likely to get usage in a bright environment.
This is one thing that MacBooks objectively do consistently better.
Blurriness is almost always due to use of xwayland.
These are completely unrelated technically.