KDE Lands Wayland Fractional Scaling Support

[Weasel]

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.

This.

PA was all about adding features because ALSA was too limited (couldn't even mix multiple sources without hardware). In fact, PA is still great at that, can easily change sources/sinks and modular.

Wayland is all about removing features that the dumbasses don't consider important, or are too paranoid about (i.e. "who would use this other than bad actors?!", since they're peasants and not power users).

PA's goal wasn't to be "slimmer" than ALSA. On the contrary.

[bple2137]

For instance XWayland applications cannot use the systray along with being unable to do most of the stuff available under Xorg.

I don't understand that one. Why my X apps like Steam, Discord, Windows apps on Wine/Proton use system tray icons and behave on Wayland exactly as they do on X11? I can literally see no difference here between Plasma X11 and Plasma Wayland. It even worked on Gnome after adding an extension (Gnome doesn't support tray at all by default regardless to what kind of session it is). I can only see that an app is running on Xwayland 1) by checking it manually using something like xprop 2) some native Wayland apps don't support window title bar icon, so it has Wayland logo instead 3) I try to use hidpi interface scaling and X app windows get wacky in one way or another.

[MorrisS.]

This is red herring (Wikipedia).

red herring means that you don't understand.

[MorrisS.]

This is red herring (Wikipedia).

https://wiki.xfce.org/releng/wayland_roadmap

Read this plan, then likely you understand better.

[MorrisS.]

No, that is irrelevant (another red herring).

Again, tell us all here, so that we all learn something: what method the KDE compositor uses to implement fractional scaling?
Just a few words are sufficient to provide an answer.

I answered to you about Xfce matter. About KDe fractional scaling ask to Nathan.

[Linuxhippy]

awesome! i can finally switch to wayland, after waiting years for a feature supported by X as well as all the other major desktop operating systems.

[MorrisS.]

Well, I don't need to ask him, because I'm, obviously, not using KDE. I think that the users of KDE should ask him.

If I turn out to be correct, than it is for the benefit of all the KDE users.

Even more, since I know a lot about image filtering, you can always ask me, and I will be glad to provide the developers of KDE with a few suggestions. I implemented efficient Lanczos filtering several times, on CPUs and by using CUDA, so I can give you a few tips.

You are assuming that KDe developers are liars doubting about their affirmations. If it is so, ask to Nathan whether KDe developers are liars.

[jamtapot]

Wayland haters are hilarious

[Sho_]

For the record, the new fractional scaling support under discussion here doesn't do any up/downsampling of windows. That was already previously supported (and KWin has a Lanczos filter since at least 2010), and it is still used with app toolkits that don't support a new Wayland protocol (in wayland-protocols v1.31, from late Novemver) that now allows the compositor and the app to agree on a fractional scale, allowing the app to optimize for it. This is what the blog is talking about. KWin now supports it, Qt supports it, GTK support is in the works.

A couple of posts earlier in the thread about image filtering and protocol-vs-compositor were incorrect; I hope this clears things up a bit.

[Sho_]

You are still slightly ambiguous to me. My interpretation of your words is that KDE supported Lanczoz filtering before. Now, for Wayland fractional scaling, the old filter is still being employed, which uses Lanczos, which is the best and recommended way to scale.

So, can I get a confirmation that I have understood you well? Just so that I know, because I'm now curious about the exact nature of the filter being employed.

wayland-protocols v1.31, released last month, added fractional scaling support to the Wayland protocol suite. If a compositor and an app both support the new protocol, then they can agree on a fractional scale and the app can optimize its rendering accordingly. The compositor will then not use any up/downsampling (image filtering) on the window at all. Of course the itself app might, but generally speaking apps will then strive to use other means of adjusting their size such as e.g. rasterizing individual line painting accordingly. This is the best for avoiding any blurriness and the progress here.

If compositor or app don't support the new protocol, typically the compositor will agree with the app on the next higher integer scale factor and then downsample. So far as I am aware, KWin uses Lanczos resampling for this (see e.g. mention here). There are some options for the filtering method used in the advanced settings GUI, though.

Implementing the new protocol in KWin is what Nate's blog was about. Qt also supports it already. Mutter (Gnome's compositor) merged support as well I believe. GTK is still pending or at least unreleased (source: Nate, I haven't checked the lastest news).