KDE Config File Lookups Now 13~16% Faster, More Fixes Ahead Of KDE Plasma 6.0

[Nth_man]

> At this point 6.0 is bug fixes only no new features, new features go to the main branch that will eventually be forked to 6.1, I see nothing special about this.

I thought 6.0 also had new features though?

He wrote "at this point". At this point, no new features are going to be added to Plasma 6.0.

New features are added to "the main branch that will eventually be forked to 6.1".

[ssokolow]

I thought 6.0 also had new features though?

They're saying that the 6.0 branch is now in feature freeze while they clean it up for release.

[Eudyptula]

Without fractional scaling support then I can see that things do look blurrier, but then that's really on the app to fix.

The problem with that is that there will always be a (a bunch of?) apps that doesn't support it, or will take its time getting support added.

It seems to me there should be a way to just increase the size of the UI in relation to physical screen size and resolution (dots per mm, taking account aspect ratio as well because that changes the equation). Why scale the entire image which would guarantee some blur to some extent when you can scale UI? My guess is that the framework is not designed such that it is able to do it for apps and that apps would have to support it. Or the framework would have to be made with adaptability in mind, which it might not be. If it was made with that in mind, not only would it look the same on the lower resolution monitor of the same size, but it would scale without problems on different sizes and resolutions too. Task bars would become bigger or smaller and the icons would just use the available space (and on super low-res screens it would go into an overflow hamburger menu or something, or go on a new line, depending on the app).

Personally, I think it matters for everything on the screen to be crisp when you are using a 4k+ monitor. Tiny text, icons or UI elements will be more legible and also be sharper when it's not scaled.

I kinda hope someone can tell me there is a very good reason it's done like this and that it isn't just lack of care regarding sharpness or laziness.

(Having said that, every time I compared, Windows would always look like a buttery FXAA mess that would make you cry and Linux would be a lot better. So at least there's a silver lining?).

I thought 6.0 also had new features though?

Yes, in comparison to Plasma 5.27. They kept adding new features and improvements for a long time, but (I think) sometime in December, as Plasma 6 matured and got close to release, they had to stop putting new stuff in and go bug-hunting and focus on polishing. It's a common practice (and the sane one, KDE is doing it right).

If they kept adding new stuff for Plasma 6 until release, new bugs and issues would appear and it wouldn't be polished and nice when it's shipped. So all new stuff after that "freeze" will be held off for the version after.

[bug77]

That honestly doesn't really make sense to me, for a FLOSS product. I could see Microsoft doing that, where they intentionally hold back bug fixes and features in Windows 12 or even 13 in order to coax people to switch, but KDE isn't profiting off individual releases. Unless 6.1 has some compatibility issue, surely, 6.0 could be using these updates. There's still another whole month until 6.0 is released.
Think of it like this:
Someone upgrades to 6.0 in early March. They report a bug and the devs are like "oh, we already patched that a month and a half ago in the 6.1 release - wait for that". I would be pretty confused why they didn't just patch it for 6.0.

I'm pretty sure 6.1 is not about bug fixes atm, but about features that didn't catch the 6.0 train. So yes, it makes sense.

I thought 6.0 also had new features though?

Of course it does. What he meant is that at this point only bug fixes land in that branch.

[yump]

Eudyptula That's what the fractional scaling protocol is for. The compositor doesn't get vector UI elements from the app, it just gets pixels, so the only thing it can possibly do is raster scaling. The only way to get unblurred scaling is for the App to know what scale factor it should render to, and for the compositor to know the app knows so that it can apply no raster scaling (as for 100% scale).

Dolphin now periodically auto-saves its open windows and tabs, so you don’t lose state if the app crashes or the system is restarted unexpectedly (Amol Godbole, Dolphin 24.05.

I'm surprised this wasn't mentioned in the Phoronix article. It's absolutely huge. Having to close Dolphin windows in the right order before rebooting to prevent loss of tabs has been a pretty big papercut.

[Eudyptula]

That's what the fractional scaling protocol is for. The compositor doesn't get vector UI elements from the app, it just gets pixels, so the only thing it can possibly do is raster scaling. The only way to get unblurred scaling is for the App to know what scale factor it should render to, and for the compositor to know the app knows so that it can apply no raster scaling (as for 100% scale).

Not entirely sure which exact part you are referring to: "that's what the fractional scaling protocol is for". You also say that the only way to get unblurred UI scaling is for the app to do the scaling itself and for the fractional scaling protocol to be aware of this and leave that app unscaled.

What I was trying to say is that it seems possible that relying on each app-developer to create UI scaling capabilities will lead to a situation where many apps just use fractional scaling to handle this instead of integrating the capability in the app itself. So you end up with fractional scaling being a crutch and as a result have a blurry UI render. On top of resource usage and decreased power efficiency.

On low-power systems with limited power profile step adjustment resolution, could it be enough to tip it over to a less favorable idle state power profile? Regardless, I think it's fair to assume fractional scaling is an extra step with increased resource usage.

So I asked if there are any reasons that the UI framework doesn't have scaling capabilities that simply enlarge elements (like toolbars) to the nearest pixel-value corresponding to the display scaling. Not scaling, but initial UI sizing presented to the renderer. If a toolbar is 30 pixels and you have a setting of 1.25x scale it would calculate 37.5 and then round to the nearest whole number as the value until the scaling setting is changed in the setting (to avoid doing the calculation for each draw). As for icons, if raster, scale appropriately and put into memory (and use higher resolution icons where available). If it's vector-based it would be the same thing in principle.

Maybe there is such a thing, maybe it depends on the framework and there is only missing communication with the compositor as the last piece missing? And that fractional scaling is simply a fallback when an app doesn't use a UI framework with support for UI scaling perhaps because the developer using a custom solution.

For GTK apps, I suppose Plasma have to understand the GTK framework's communication (if it has UI scaling functionality). Same with Qt.

Maybe it doesn't work this way. In which case I ask, why not? It's seems like an essential thing as the need for UI scaling will always be there. Just doing raster scaling on top of a rendered UI/window seems inefficient in terms of performance and power consumption.

[yump]

Not entirely sure which exact part you are referring to: "that's what the fractional scaling protocol is for". You also say that the only way to get unblurred UI scaling is for the app to do the scaling itself and for the fractional scaling protocol to be aware of this and leave that app unscaled.

Unblurred scaling is what the fractional scaling protocol is for. Blurry scaling is what you get when the apps don't support the fractional scaling protocol.

[...]So I asked if there are any reasons that the UI framework doesn't have scaling capabilities that simply enlarge elements (like toolbars) to the nearest pixel-value corresponding to the display scaling. Not scaling, but initial UI sizing presented to the renderer. If a toolbar is 30 pixels and you have a setting of 1.25x scale it would calculate 37.5 and then round to the nearest whole number as the value until the scaling setting is changed in the setting (to avoid doing the calculation for each draw). As for icons, if raster, scale appropriately and put into memory (and use higher resolution icons where available). If it's vector-based it would be the same thing in principle.

The thing you are describing is the fractional scaling protocol. The protocol is how the app asks what the display scale factor is, and then tells the compositor that it is already rendering at the target size so it shouldn't be raster-scaled.

[Eudyptula]

Unblurred scaling is what the fractional scaling protocol is for. Blurry scaling is what you get when the apps don't support the fractional scaling protocol.


The thing you are describing is the fractional scaling protocol. The protocol is how the app asks what the display scale factor is, and then tells the compositor that it is already rendering at the target size so it shouldn't be raster-scaled.

Aah, I see. Thanks for providing this information.

But what about the method of UI scaling? Is it functionality provided by the frameworks or does it require the app developers to implement their own methods?

[yump]

But what about the method of UI scaling? Is it functionality provided by the frameworks or does it require the app developers to implement their own methods?

It is/will be provided by the frameworks. Mostly. Things like SDL may not, and of course finished apps and frameworks won't be updated to support it.