KDE Lands Wayland Fractional Scaling Support

[Sho_]

It's certainly a possibility that thinking on this could evolve more in the future based on empirical data (e.g., the problematic apps prove more sticky than expected), yeah. Even then however it could be that postponing the effort is still the right call, if the freed-up dev resources are put to another good purpose in the meantime. That depends on what the success metric you optimize for is, and so on (and also keep in mind that to some extent that success metric is personal and individual to each contributor in most FOSS projects).

[Sho_]

It's not that you're wrong, but I think it's reasonable to assume that the majority of applications use a toolkit where part of the toolkit's value prop is to make this easy on the developer, or are the type of application where scaling is relatively easy/natural to achieve because supporting variable target resolution is for example relevant to adapting to machine peformance (i.e., 3D games). Then the second assumption (and this is what lead me to frame it as a backwards compatibility issue) is that the number (or fraction) of apps which don't support scaling due to being legacy or unmaintained is larger than the number (or fraction) of modern apps that refuse to support scaling, and that those fall out of use over time or eventually do get fixed.

There may be some modern/maintained apps that refuse to do scaling, but then it begs the question whether spending effort on them is worth spending the required resources. I could totally understand if some compositor devs decided they must offer those options to have a full set of tools for dealing with all conceivable scenarios. It's also fine to argue for that. But I predict most teams will likely decide to aim for something different in terms of dev resource allocation.

Incidentally, the best use case I can come up for this is in fact games you can't afford to render at hi-dpi resolutions and then want to upsample as a compromise. For a gaming-optimized compositor (e.g. gamescope, which you can nest) it'd not be a bad thing to support. Nesting compositors and making that low-overhead is also a valid path to pursue here in terms of how to compose a solution to the overall problem. gamescope also supports exotic HW-accelerated scaling stuff like nVidia's image scaling and AMD Super Resolution that outperform basic Lanczos for this type of window content. Game consoles today also tend to do dynamic res scaling where the game drops resolution situationally and upsampling is used temporarily to account for it without having to switch video modes.

Most desktop apps don't operate near the machine performance ceiling enough though to warrant that type of sophistication, and changing res+scaling dynamically is also more visually obvious in their type of content.

[billyswong]

I did, but all the crucial information is missing.

Can you point me to the first place where the word "Lanczos" is mentioned? Perhaps I have missed it.

Since the native fractional scaling support in Wayland is all about support of fractional scaling done by the application side, it is normal for no resampling / filtering algorithm mentioned in this news. How an application implement fractional scaling internally is offtopic.

[billyswong]

This is area where I think we just need per application controls. With controls providing the following options
1) Do not ask this application to fractional scale because it fractional scale implementation is busted.
2) Do not ask this application to interger scale because it integer scale implementation is busted.
3) Method option for compositor side integer upscale.
4) Method option for compositor side fractional scale.
5) Freetype overrides(force hinting on and off and so on)
Yes all these controls as .desktop entries.

I think some compositor may not want to implement choice 1 and choice 2, as they are bug mitigation scheme for misbehaving software. But 3 and 4 do matter. Some software graphics favour antialiasing while some favour jaggish pixels. There should be some way to combine choices for 3, 4, 5 into one list of scaling preference.

[Quackdoc]

the only OS with good scaling is android xD.

but the big thing is the compositor being able to just render at native. it doesn't matter to me what apps that don't scale do, they can ignore it, they can be upscaled, or 2x scale and downscale, it matters not to me. and I figure most people typically won't care either. for me, it's as simple as avoiding GTK apps like the plague that they are, im just worried how waydroid is gonna fair with this, but thats something that can be figured out.

[Sho_]

Speaking personally, this seems like a solid enumation of what could be provided as user-configurable options. I don't know if the effort to do so would be worth it vs. spending the effort on fixing the apps though, since fixing the apps would always produce the best visual result and more options have an ongoing maintenance burden. There's a cut-off there, and where to draw the line (given finite resources to do stuff) depends on complex predictions of the effort needed to fix the apps or how likely it is users will stick to apps not sufficiently maintained to fix this (since those apps will likely also fall behind the times in other ways and lose favor). You can spend a lot of effort on options that only remain useful for so long, and some decisions can also artificially prolong a state of affairs in the ecosystem.

I wouldn't be surprised if e.g. KWin adds some more options down the line to configure behavior per-window or per-app (since it already has a Window Rules infra in place), but I'll predict most compositor devs will prefer to leave it at "we now have infra for apps to do all the right things; apps, please do so".

These kinds of decisions (how far to take backward compatibility) are always among the hardest for devs and users also fall on different sides of the issue in terms of where they would prefer devs spend their resources. I'd say Linux tends to fall inbetween MacOS and Windows there usually, with MacOS rather brutally killing older APIs and behaviors and expecting app developers to go with the times, and Windows maximizing on backward compat.

[Sho_]

Where does that info come from? The only thing I can find on it is GNOME devs refusing to do anything about since it requires too much internal rework and might result in API breakage (for no clear reason).

https://gitlab.gnome.org/GNOME/gtk/-/issues/4345

As mentioned in a later comment, I was basing it on Nate's blog + I saw an implementation of the compositor side being submitted for Mutter, which together made me optimistic since it seems so entirely sensible to support this. I wasn't aware of that GTK ticket you linked and it leaves me quite surprised how dismissive and negative the convo there is. Sorry about the misinfo.

[Azrael5]

As far as me, Kde Neon is not usable under Wayland if an Nvidia card run although Mesa drivers. The system freezes almost immediately on Nvidia 7xx GPu.
Meanwhile, I don't know how Nvidia proprietary drivers are evolving to match Wayland.

[openminded]

Congrats Plasma devs! Plasma Wayland is still a no-go for me due to a number of missing features like custom touchpad gestures but given the enormous amount of work already landed I can see that it might change in a year or two, so fingers crossed.

[jamtapot]

Amazing. In that case, I'm actually quite impressed with the high-level of support for fractional scaling that KDE offers. I can't imagine any better solution than the one you have described.

So, the reason why some users reported blurriness in this thread must be other than the one I have guessed.

Did you just not even bother to read what the fractional scaling protocol entailed and how it worked? It would have been obvious if you had rather than going off on a tangent about Lanczos filtering.