Unify UI scaling methods
Open, Needs TriagePublic

Description

Right now we have a few user-visible ways of increasing the size of user interface elements:

  • User interface scaling in the KScreen KCM
  • Force Fonts DPI in the Fonts KCM
  • Adjusting the font size in the Fonts KCM automatically adjusts the size of user interface elements in a similar manner to the Force Fonts DPI setting
  • The Resolution slider/combobox in the KScreen KCM. This is probably not something people use for scaling the UI because the results are pixellated and ugly, so we can probably ignore it here

It would be nice of we could offer a single knob for "here's how you generically scale the whole user interface", because right now it's not clear. For example, if I want to make everything 10% bigger, the following three methods all work (for some definition of "work"):

  • Increase the size of the fonts by 1pt (from 10 to 11) in the Fonts KCM; everything seems to get about 10% bigger
  • Increase the font DPI from 96 to 106 in the Fonts KCM
  • Set a 1.1 scale factor in the KScreen KCM

What do we do about this?

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.

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)

abetts added a subscriber: abetts.Aug 26 2018, 5:04 AM

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.

romangg added a comment.EditedAug 27 2018, 7:37 AM

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.

rizzitello added a comment.EditedOct 18 2018, 6:20 PM

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.

alexde added a subscriber: alexde.Oct 26 2018, 9:52 AM
cfeck added a subscriber: cfeck.Dec 27 2018, 9:49 PM

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?

rooty added a subscriber: rooty.Jan 30 2019, 1:16 AM

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

-Simple Test Application to view Scaling based on Font Metrics as well as provide some info about the screens Physical and logical DPI settings.

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.

LeGast00n added a subscriber: LeGast00n.EditedJun 4 2019, 6:34 AM

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.

ngraham renamed this task from UI scaling to Unify UI scaling methods.Jun 5 2019, 12:56 PM
ngraham added a subscriber: mart.Jun 21 2019, 1:27 PM

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