KDE Lands Wayland Fractional Scaling Support

[Sho_]

[QUOTE=xfcemint;n1363126]

This integer-upscale first is going to look excellent only if the app can truly render itself at higher integer resolution (as opposed to just making multiple identical copies of each pixel). If the app tries to fake the higher integer scale, then it won't look so good even after Lanczos is applied.

So, it would be good to give some kind of an option to users: if the app tries to fake the higher integer resolution, then it's better to apply Lanczos straight to 1× resolution.

This is how it works. There's no upsampling to integer first, only downsampling for apps that don't support fractional scaling, but do support integer scaling (this is by now most apps using a maintained toolkit, though, since it was in the protocol from the start). Unscaled apps are directly upsampled to the target fractional scale.

That said, until 5.25 or 5.26 or so, scaling of XWayland windows wasn't supported well and caused pixelated windows even with integer scaling due to other infra problems. That was since fixed in the stack and KWin, and with the further addition of this new fractional protocol in 5.27 overall scaling is now in very good shape.

[oiaohm]

All what you wrote about KDE filtering is an excellant design, except for this part which I'm quoting. I think that it is not always a good idea to first upsample by integer, then to apply Lanczos.

This integer-upscale first is going to look excellent only if the app can truly render itself at higher integer resolution (as opposed to just making multiple identical copies of each pixel). If the app tries to fake the higher integer scale, then it won't look so good even after Lanczos is applied.

Not quite right.

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.

How it goes south I have been describing over and over again. Take it in this time.

Lets say application cannot or will not upscale to the higher integer. What is stopping the compositor applying anti-aliasing.


There is ugly fonts and blurry fonts those are two different things.
Ugly fonts are rounding issues caused by downscaling made less visible when you have auto-hint on in freetype.
https://www.reddit.com/r/wayland/com...nd_ugly_fonts/ this link is the problem ugly fonts.

Blurry fonts
https://www.omgubuntu.co.uk/2022/10/...d-fonts-ubuntu
Notice how person is being recommend here to use wayland mode and avoid Xwayland not all wayland compositors have Xwayland able to do dpi scaling. Any program that will or cannot upscale the result can be Blurry fonts.

(as opposed to just making multiple identical copies of each pixel)

that not what happens with most compositors when application cannot upscale. Most use anti-aliasing up-scaling so the pixels are not identical copies.

Its freetype auto-hint that hides the ugly fonts issue by adding a little blur with compositor anti-aliasing upscale(because application will not upscale itself) that added a little more blur that ends in too much blur that is the cause of Blurry fonts.

Multiple identical copies method you described of up scaling normally lands you with ugly fonts or jagged fonts. Yes jagged when integer upscale then comes ugly when downscaled.

The reality is most Wayland compositors have quite good implementations of the compositor side scaling stuff. I have not found one that was not one of the best of class down-scaling solutions. Compositor up-scaling because application cannot lot of these do end up with Jagged/ugly(not anti-aliasing compositor up-scaling) or Blurry(anti-aliasing compositor up-scaling of some form).

Of course there are going to be applications that cannot scale self. People need to choose what one they can live with for the applications that cannot be scaled. Jagged/ugly or Blurry as worst out come. Even the new FSR and the like anti-aliasing scaling can still make blurry when up-scaling.

Yes I wish more compositors did provide the controls to let people choose per applications what compositor side upscale to apply.

Horrible point here is too blurry fonts cause more eyestrain than jagged/ugly fonts.

If the app tries to fake the higher integer scale, then it won't look so good even after Lanczos is applied.

This is always going to be a problem. Yes of application says to compositor yes I can upscale either fractional or integer but internally the applications implementation is totally horrible to the point of being worse than the compositors blurry or jagged/ugly.

We need the compositor upscale system as fallback. Yes people come out saying X11 dpi method is good while totally ignoring all the applications where its not.

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.

[middy]

does KDE offer a xwayland on demand and close after xwayland programs are terminated? gnome has that and i really liked it because its nice only having xwayland up and running when something is actually using it.

[pracedru]

This great stuff really I like. You amazing me.

Ohh nice. A hit on some ones English grammar with a stereotype. Its not like oaiohm is attacking you personally. Yet you don't hesitate to do a crude ad hominem. That is pretty awful xfcemint.

[pracedru]

Wayland is nothing like PA.

PA retains a near perfect ALSA compatibility and offers great features on top of it, first of all, multiplexing which was horrible to set up in ALSA using dmix and then applications still could open ALSA devices exclusively. PA got into a great working shape in a few years at most.

We've had Wayland for close to 15 years now and it's still a bloody mess and there's little to no compatibility with X11. For instance XWayland applications cannot use the systray along with being unable to do most of the stuff available under Xorg.

I am using X11 apps in Xwayland while having their systray features wotrking just fine.

[avis]

I am using X11 apps in Xwayland while having their systray features wotrking just fine.

Under KDE/Gnome? OK. What about a myriad of other Wayland implementations/compositors?

[Quackdoc]

GTK support is in the works.

where is the info on this?

[dfyt]

Does this mean I can use the KDE recommended way by changing "global scale" Vs forcing font DPI? Forcing font DPI looks makes Windows and fonts crisp on Wayland and X11. Using gs is currently a blurry mess with titlebars Windows etc and looks pixilated in some instances. Gs also affects window absolute positions with kwin.

[Quackdoc]

Does this mean I can use the KDE recommended way by changing "global scale" Vs forcing font DPI? Forcing font DPI looks makes Windows and fonts crisp on Wayland and X11. Using gs is currently a blurry mess with titlebars Windows etc and looks pixilated in some instances. Gs also affects window absolute positions with kwin.

I hope so, it should, but I haven't tested yet

[pracedru]

Under KDE/Gnome? OK. What about a myriad of other Wayland implementations/compositors?

I'm running Gnome on both desktop and laptop at the moment.
Wayland isn't really ready for KDE so I haven't really tried it lately. I can just try logging into KDE and see if it works.