We also have 2 independent tasks

• a user wanting smaller/bigger fonts because they prefer smaller/bigger fonts

• changing stuff because their hardware has a different resolution and they want to see things the same (typically monitors are normal 1.5x or 2x ) scaling by 1.1 isn't really the point.

They're very different tasks as

we need to store data per screen or globally.

Ignoring plasma one is about fonts the other is everything

Further ignoring X the scaling on Wayland should be done at some point automatically by comparing physical dimensions of a screen and its resolution. In 99% of cases the user should not need to change the scale factor in the KScreenKCM (which should have a special scale combo box value "automatic") to have a nicely sized Ui.

Changing fonts values is as David says just personal preference and should not be necessary to adapt for high DPI screens. I don't know why there are two settings needed for doing this (fonts DPI and fonts size). Sounds like fonts size is the one you normally would change if you want to have bigger/smaller fonts.

Wayland should be automatic on startup, (Whether it works reliably is a different story) putting that in the combo makes sense.

DPI historically exists purely for correct Anti aliasing.
It was then repurposed for pseudo high DPI bodging, to a point that its hard to remove.

In T9500#156848, @davidedmundson wrote:

We also have 2 independent tasks

• a user wanting smaller/bigger fonts because they prefer smaller/bigger fonts

Right, this is separate, though I'm not sure what to do with the fact that it happens to increase the UI size as well.

• changing stuff because their hardware has a different resolution and they want to see things the same (typically monitors are normal 1.5x or 2x ) scaling by 1.1 isn't really the point.

If one of our goals is to provide consistent physical sizes, odd scale factors may make sense given the huge diversity of screen sizes and pixel densities.

For example let's consider (for purposes of illustration) a laptop with a 15.4" 1080p screen to provide our UI element size benchmark. To make the UI elements on a 13.3" 1080p display match the benchmark size, a 1.15x scale factor is needed (otherwise they will be visibly smaller). The same would be true if these screens were HiDPI instead: the 15.4" 4k screen would need a simple 2x scale factor, while the 13.3" 4k screen would need a 2.3x scale factor to match the benchmark size.

(note: I have no idea what we actually consider our benchmark for the physical sizes of UI elements, or if we have one)

If one of our goals is to provide consistent physical sizes, odd scale factors may make sense given the huge diversity of screen sizes and pixel densities.

For example let's consider (for purposes of illustration) a laptop with a 15.4" 1080p screen to provide our UI element size benchmark. To make the UI elements on a 13.3" 1080p display match the benchmark size, a 1.15x scale factor is needed (otherwise they will be visibly smaller). The same would be true if these screens were HiDPI instead: the 15.4" 4k screen would need a simple 2x scale factor, while the 13.3" 4k screen would need a 2.3x scale factor to match the benchmark size.

(note: I have no idea what we actually consider our benchmark for the physical sizes of UI elements, or if we have one)

And this is something I would like to know as well. I don't know if it is possible technically since our software can be in many different screen sizes. When working at openSUSE, we decided that it was best to focus on 4 main resolutions that seemed to be more universal. However, KDE could take this further by adding many more form factors while keeping that visual sizing consistency that Nate is talking about. If this is technically possible, I think we should strive to have this.

I didn't notice the comment about the 1.1 scaling not being the point. For me it is out of question that these odd factors need to be supported, since screens come in all kind of different sizes. As far as I know it is also doable with our current tech. But at first I would like to limit the available factors to

1, 1.1, 1.2, ..., 1.8, 1.9, 2, 2.1, ..., 2.9, 3, 3.1, ... (max value?)

So only to two significant digits, since I have the presumption that more exact scaling won't make much of a difference anymore and this would limit the complexity for the user. If we find out otherwise we can still change.

As far as I know it is also doable with our current tech.

Not really.

You can either be:

1. pixel aligned
2. fractionally scaled

Doing both is /physically/ impossible. (including with the plasma approach)

Paint scaling 1.1 will be bad.

What I used to have before Qt added fractional support was that slider still existed altering the fontDPI for the fractional values then the painted scale at either 1 or 2. Meaning a 1.3 scale would have the button the size it should be, but with the rounded corner radius of a 1x screen, then at 2x you'd have a good size button and have the correct corners. I was pushed into adding fractional support when Qt added it, but frankly the old version worked better practically.

Thanks for that info, David. I can confirm that 1.1x Qt scaling looks... special. :) And that increasing the font DPI by 10% produces a superior visual result.

I don't have a preference regarding how this is all implemented on the backend. But I do agree with Roman that it would be nice if we could support the odd sizes, and not just 1x, 1.5x, 2x, etc (I can live with losing 1.15x :) ). Our currently scaling slider only supports those anyway.

Windows 10 scaling allows for 1x, 1.25x, 1.5x, 1.75x, 2x, 2.25x, ... scaling. While KDE doesn't have to be aligned, I think Windows devs were onto something:

• limited number of options decreases the likelihood of users picking 1.1x or 1.4x which may seem like a good fit, but produce less-than-ideal results
• limited number of options allows testing apps easier for all possible scaling options
• still a good enough granularity for vast majority of users

That's a great point, @gvarsanyi!

From my experience ui scaling is the wrong way to deal with HiDpi. The most important thing with HiDpi Screen is that the DPI for the display is set correctly. Simply detecting and setting the correct DPI for the screen gets us 99% correct scaling with out the need to double up pixels. The only place where this is still an issue is with icons and that is usually the fault of the application setting them to a fixed size. Most applications can be "fixed" by using the option AA_UseHighDpiPixmaps or by using fontMetrics to set the icons relative to the rendered text size. I think that using scaling in not the correct approach and we should instead be working on making sure under kwin dpi is set correctly for our uses. This should help with both the hidpi desktop and low dpi displays.

You have your terms mixed, you said we shouldn't do UI scaling and then mentioned something that requires Qt's UI scaling.

The Qt scaling for Icons seams to be independent of the "scale" were using in kwin. I need to double check this on my home machine but if i remember correctly on my Screen where use a scale of 1 (in kwin) devicePixelRatio() returns 1.8[/s] (based on the screens physicalDPI dpi iirc). .(edit) I was mistaking this for physicalDPIX/Y here. Those return the screens dpi. there is not an easy fix, icons must be adjusted for this. (/edit) I Honestly think using the fontMetrics.height() to decide how large a icons should be looks better then using the AA_UseHighDpiPixmaps option since you get an icon that is the size of the font always avoiding future dpi issues.

An idea from @davidedmundson https://bugs.kde.org/show_bug.cgi?id=397421:

Frankly my original mode before someone added Qt fractional support was better - the slider would control the font DPI and Qt would snap between 1x and 2x after you reach a certain threshold.

I would be happy to explore options that separate the two concepts of Qt scaling and font DPI setting - though I'm not exactly sure what.

That would then allow us to make Qt fractional in a more hidden "advanced mode" with more descriptive text.

Thoughts?

In T9500#174855, @ngraham wrote:

An idea from @davidedmundson https://bugs.kde.org/show_bug.cgi?id=397421:

Frankly my original mode before someone added Qt fractional support was better - the slider would control the font DPI and Qt would snap between 1x and 2x after you reach a certain threshold.

I would be happy to explore options that separate the two concepts of Qt scaling and font DPI setting - though I'm not exactly sure what.

That would then allow us to make Qt fractional in a more hidden "advanced mode" with more descriptive text.

Thoughts?

In my experience, fractional scaling ends up leaving certain UI elements looking fine (Dolphin right click menu) and certain others disproportionate (right clicking on Kicker/Kickoff), and I don't know if setting the font DPI to a different value is going to help that particular scenario.

As far as snapping goes, I wouldn't mind having it also snap at 1.5x and 2.5x while we're at it. But yes, considering that there are issues with Qt fractional scaling, this proposal sounds like a good idea (retain both but put Qt fractional scaling in an advanced mode type thing).

• correct font rendering for picky font people (the original purpose 10 years ago)

I proudly count myself among said picky people :D

Ideally you want to set you font DPI to the reported physical DPI and Your screen scaling to 1. In order to view the effect of using fontMetrics . The Gui should look fine no matter what your scaling is as well since the icon and indicator sizes are based on your rendered font size.

That's going back to very much how we used to do it before the Qt support - go through every single possible piece of code and multiply it by a factor.

The plasma toolkit is based entirely around that approach from the ground up. It's not quite as great as it seems.

(btw, if you personally want this approach, you can use https://gist.github.com/Tar-Dingens/c7a540af91ec46cb9e57e2d03a765a95 which is basically what you're doing but slightly lower in the stack in breeze)

It falls apart with dual monitor of different scales, you have to worry about pixel alignment everywhere, and it will never look exactly right as there are hardcoded values in QWidgets themselves.

Even on plasma mobile which is a single screen on constant size I was asked recently to switch it from plasma scaling to Qt/Wayland scaling.

Having a HiDPI screen, I support every effort towards improving this,

Taking it on from the last comment and with a modest understanding of the software architecture, the previous remark hints that HiDPI needs to be managed at screen level. Taking into account the diversity of widgets, each widget should advertise its own HiDPI situation for screen-specific rendering to happen properly (or it might be figured out/limited, based on e.g. window size).

That would imply a scaling ratio for the widget rendering on the screen = screen dot density / widget dot density.

We discussed this at the Plasma/Usability sprint and came up with the following:

• Move the "Force Fonts DPI" spinbox into the "screen scaling" window to reinforce that the two are intimately connected
• Change its label to "Override Font DPI" and make it disabled until a checkbox is checked
• Dynamically change the value displayed in the spinbox as the slider is moved to communicate that the scaling slider automatically changes the font DPI, so there's no need to fiddle with it by hand

So over time we've started to add messages and warnings throughout System Settings that direct people to the KScreen scaling system.

• In the Fonts KCM, when you set the font higher than 14, a warning message appears telling you to use KScreen, with a button you can click to go there
• In the Icons KCM, in the dialog to change icon sizes, there's a message appears telling you to use KScreen to do scaling, with a button you can click to go there

For Plasma 6, I would like to make the following additional changes:

• Turn on Qt scaling for X11 by default, bugs and all (hopefully following a push to fix as many of those bugs as possible)
• Delete the feature to override the font DPI on both X11 and Wayland; people using it need to use the KScreen scaling system instead, which is much better at this point
• Delete the feature to change icon sizes in the Icons KCM