Define a reference appearance and help users have a consistent experience of on-screen object sizes
Closed, ResolvedPublic

Description

The VDG team keeps running into a variety of inter-related problems regarding the apparent sizes of things on the screen that are preventing us from achieving consensus on the ideal size of various UI elements.

Essentially, each user experiences the size of items on screen differently due to widely varying sizes, resolutions, and viewing distances of screens, compounded by scale factors and scaling methods. Because we haven't defined what things are supposed to look like with a reference/baseline screen size and resolution, it is impossible to have a conceptually sound design discussion about object sizing at any other size, let alone in general.

From what I can tell, the historically intended screen PPI value is 96 (immortalized in X11's default DPI value, and visible in our Fonts KCM). This PPI value is only seen for desktop displays, which makes sense given X11's roots, so let's use the desktop UX as a baseline. Various online sources indicate that a desktop screen should be placed about 27" (68.5cm) from the user's face, and at that distance, a 23" (58cm) display is pretty comfortable. I personally have a 27" (68.5cm) display, which is 115% larger and would therefore look the same from 115% farther away, or 31" (81cm). This is in fact about as far away as I naturally sit from it, so I think this works as a baseline.

Let's choose 1920x1080 as the resolution for our 23" (58cm) display, which gives us the desired 96 PPI on that screen. A user with this setup will thus roughly view the system's visuals the way they were intended to be seen:

If a person uses a laptop, that person is likely using the laptop a bit closer to their face compared to a desktop screen. About 23" (58.5cm) seems about right, based on my own usage. That's 17% closer than the desktop screen is, which means that a laptop screen's PPI should also be about 17% greater. This gives us a target laptop PPI of 112.

A 13.3" (34cm) 1366x720 screen is 118 PPI, which is pretty close to that. Unfortunately most 1366x720 laptop screens are very low quality, sold as a budget option. A 1440p resolution at that same screen size provides us 236 PPI, which means you can use a 200% scale factor to make everything look perfect, and the quality is typically very high. Unfortunately again, most laptop manufacturers typically do not offer this or similar resolutions, only Apple and Lenovo do--and for Lenovo, it's only one option among many.

Instead, most laptops these days provide a 1080p display for all sizes between 13.3" (34cm) and 17" (43cm) which produce PPI values of between 129 and 165.

129 PPI makes everything look close-ish to the right size on a 17" (43cm) screen, but the 165 PPI 13.3" (34cm) screen makes everything much much much too small at 100% scale. Without knowing about or using fractional scaling, the user will be constantly tempted to make things bigger in an ad-hoc way, by raising the font sizes, increasing their panel thickness, increasing icon sizes in Dolphin and Plasma's Folder View, zooming in on all the web pages they view, and so on. A 4K screens at one of these physical sizes doubles the PPI, so using a nice round 200% scale factor brings you back to the original problem of everything looking tiny. They are crisp and sharp, but still tiny! My only conclusion is that using 1080p and 4K resolutions for small laptop computer screens has been a terrible industry-wide mistake, and our users are suffering as a result. We cannot change the direction of the industry, but we can provide software tools to adapt. In this case, that means fractional scaling.

I believe this is what's behind the persistent criticisms we face from different users that things are too big or too small; too cramped or with too much padding--sometimes simultaneously. We need to define once and for all the way things are supposed to look by default, and help these users reach that appearance.


I would therefore like to make a few proposals:

  1. We define that the baseline appearance is experienced by sitting 27" away from a 23" 1080p screen (or 4k with a 200% scale factor), as it matches the original DPI value.
  1. Given this baseline size, we use that to decide what's too big and what's too small. For example perhaps at this size, the font size, panel thickness, titlebar size, cursor size etc could stand to be adjusted one way or the other. Hopefully it should be obvious once we have a reference appearance that's supposed to look perfect.
  1. We put real effort and resources into making fractional scaling work properly and avoid as many technical and visual glitches as possible (see T9500). This may involve clever hacks like changing the font size to 12pt under the hood if the user selects 120% scaling, instead of actually doing the scaling (just an idea). It may require truly horrible hacks to make GTK apps match the same scale as KDE apps. I know that achieving perfection is impossible; a certain amount of this is inevitable and should be minimized rather than eliminated. The net result should be to resolve T9500 and make it easy for users to adjust the scale in a way that works.
  1. We apply by default a 125% fractional scale factor for the following displays to get them into the realm of a sane PPI value that won't leave their users squinting at everything:

13.3" (34cm) 1080p (125% scale becomes effectively 132 PPI)
14" (35.5cm) 1080p (125% scale becomes effectively 126 PPI)

(For people with these screen sizes and a 4K screen, we would obviously double the scale factor to 250%)

  1. Beyond this, for people who want to make everything on the screen a bit larger or smaller to suit their tastes or eyesight, we declare that primary tool to make scale screen elements is the scaling slider in KScreen. Not adjusting the font size, not adjusting the font DPI, not adjusting the resolution, not adjusting the panel thickness or icon sizes or or the zoom factor of websites--just the Qt scaling system in the KScreen KCM. One thing. Just that. We don't remove the other things of course, but we declare once and for all that Qt scaling is the primary and only formally supported method to accomplish the goal of making everything bigger or smaller.

This isn't perfect, but I think it's much better than the status quo and solves many persistent problems.

Thoughts?

Related Objects

ngraham created this task.May 14 2020, 6:07 PM
ngraham triaged this task as Normal priority.
ognarb added a subscriber: ognarb.May 14 2020, 6:51 PM

This sounds good to me overall. I am not that familiar with the technicalities of the different scaling methods (which seems to be quite a difficult subject) so I can't comment too much on this. To me it looks like proposal 3, 5 and 6 depend on proposal 4 e.g. the 135% scale factor in proposal 5 should normally be avoided AFAIK.

Overall having a reference size written down somewhere definitely seems necessary because of the reasons you mentioned. Choosing 1080p 23"/58.4cm at a distance 27"/68.6cm as the reference appearance/size seems lke a good choice to me because it is AFAIK quite a normal setup at the moment and will IMHO stay one for the foreseeable future even though ppl are beginning to favour HiDPI. The conversions also seem to work out nicely.

Having a single point for the user to change scaling also seems like a good idea to me. The situation as it is now that users that want to increase the size of elements are sometimes supposed to change font sizes and sometimes overall scaling isn't ideal. The "clever hacks" should be communicated to the user though maybe making it necessary to have a scaling slider that is somewhat independent of the scaling slider in KScreen.

I agree with the sentiment of proposal 6 that everything should be bigger by default but this should happen by redefining the size of 100% which is what proposal 2 is about instead of applying a 110% scale factor.
But these are mostly details. +1 to the great scheme of this task.

felixernst updated the task description. (Show Details)May 16 2020, 1:53 PM

I've been using an effective 125% scale factor on my 13.3" FHD screen laptop and it magically made everything feel a ton better. We might want to consider that.

ndavis added a subscriber: ndavis.Jun 14 2020, 6:09 AM

I think I agree with the general idea, but it's a bit hard to fully grasp the scope of what must be done and I'm not sure what our first steps should be.

churaev added a subscriber: churaev.EditedJun 14 2020, 4:22 PM

I think I agree with the general idea, but it's a bit hard to fully grasp the scope of what must be done and I'm not sure what our first steps should be.

If the intent is to make KDE and GNU/Linux in general to look truly right with fractional scale factors, I think the best first step would be a few high-profile KDE developers like @ngraham writing some blog posts, and I mean this sincerely.

The prevalent FOSS approach to UI scaling is, in my mind, fundamentally wrong, and fixing it would be non-trivial collective effort involving both toolkit and application developers, which would require a difficult-to-reach consensus, and unfortunately people seem to retreat into the depths denial in such situations, convincing themselves that the problem is either unsolvable (self-fulfilling prophecy), or does not exist at all (rationalization, The Fox and the Grapes), so getting toolkit developers to fix it would most likely take multiple well-known and respected FOSS developers (halo effect, in-group favoritism) speaking up (see for example the "Present Windows" middle-click debacle, where the "peasants" were dismissed completely, and it took @ngraham to convince the KWin developers to reconsider their decision).

As to why I think the current approach is wrong: when making icons, you carefully align the lines with the pixel grid, right? Guess what happens if you scale a Qt app to 125% - icons, frames and separators are no longer well-aligned, making them look blurry, and sometimes causing different sides of the same frame to have different apparent thickness (when some of the sides are better-aligned with the pixel grid than others). Well, at least Qt doesn't render at 200% and then downscale to 125% like GNOME (notice the "May increase power usage, lower speed, or reduce display sharpness." warning in the "Displays" section of GNOME Settings)...

If GTK and Qt simply did what Plasma does right now: i.e. manually scale UI distances using round(x * scale), both high-DPI and small screens would probably be much better supported than they currently are... And certainly the icons in KWin and Plasma menus wouldn't be tiny in high-DPI mode, something which @ngraham complained about in his laptop blog post...

Yes, there would be tiny widgets in various applications that would have to be fixed, and this is probably why the flawed approach was chosen - fewer code changes and less testing are needed to make applications at least usable, but ultimately you can't abstract physical pixels away and make things look right all at the same time...

I guess the toolkit developers expected super high-density displays to take the world by storm so misalignments wouldn't matter, but it just didn't pan out...

@churaev Please don't derail the discussion.

I don't think you understand how icons work and I'm already aware of the problems icons have with fractional scaling. There's nothing that can be done to prevent our icons from looking wrong on fractional scales besides things that would require either thousands of new icons or require us to abandon compatibility with existing software, all of which is impractical. However, icons are off topic.

This is about fixing UI scaling issues in a practical way with the technology we have, not finding a perfect universal cure to fractional scaling issues that would require us to abandon or rework a lot of existing software.

churaev added a comment.EditedJun 15 2020, 8:55 PM

@churaev Please don't derail the discussion.

I'm not derailing the discussion, I'm simply describing the only possible way that this issue can be properly solved.

Anyway, I did some experimenting on the Breeze style, using 100% Qt scale and then manually multiplying by the scale factor where needed, and here are the results:

All 3 are real programs. Some thoughts:

  • It's not actually difficult, just tedious...
  • It's not possible to perfectly match the reference appearance while keeping things crisp, especially at low scale factors...
  • Human logic is required (e.g. where to use round vs floor vs ceil) for best appearance at low scale factors.
  • No visual glitches in menus!
  • There's no way to make QIcon load 200% icons at 100% scale, that's why the ✓ icon is so thin in the proper scaling version.

I think you already posted this to reddit, right? https://www.reddit.com/r/kde/comments/h9pkpy/crazy_idea_adopt_the_only_true_approach_to/

And @davidedmundson made a reply: https://www.reddit.com/r/kde/comments/h9pkpy/crazy_idea_adopt_the_only_true_approach_to/fv3s1yh/:

So to give a lengthy reply. There isn't a "only true" approach, it's highly subjective and forever going in circles.

It's not a new idea, nor that crazy.

It's what we did first in plasma, yet since has had repeated pushback from visual people pushing for going tor the lower level automatic approach.

There's also a whole breeze fork somewhere doing this. Probably on github somewhere.

It's a no-go for upstream with everything as-is currently, if we disable Qt's scaling we don't set wayland's wl_surface.scale value which breaks more. (Let alone all the trillion changes we would have to make)

I think it's also easy to underestimate how amazing QPainter is at a low level, it can snap things to pixels if used properly, at which point there's no real difference between rounding and painting and painting with rounding. There's a few QPen/QPainter hints we could make more use of.

So perhaps we just need to make better use of the QPainter Magic that David mentions.


On a visual level, personally I think 200% on a 4k screen scaling reveals that the 1px stroke widths of our icons is too thin. I actually prefer the blurry versions because they result in a thicker apparent stroke width. But of course if we want to change that, it should ideally be done in the (thousands and thousands) of icons, not accidentally by scaling things wrong.

ngraham added a subscriber: broulik.Jul 9 2020, 2:56 PM

After living with a 4K 14" screen for a bit now, I've changed my mind.

@broulik was right all along with his evangelism for 1440p or 1366x720 resolutions for smaller 13-14" screens. On one of those small screen sizes, 1080p and 4K make everything on screen much too small, which I see now was the root cause of me pushing for increasing the font size and the default panel thickness so high. In the end I set a 125% scale factor on my old 1080p screen and I now use a 250% scale factor on my 4k screen and suddenly everything seems so much more visually coherent without manually increasing the size of anything. It's quite obvious that this is the size that everything was designed to be displayed at.

Unfortunately, most laptop manufacturers don't sell machines with 1440p screens in the 13-14" range, and most 1366x720 screens are sold as budget-friendly options and look terrible, so nobody who cares about visual fidelity would want to buy one. In practice, most of the time your only options are 1080p and 4K, which both produce a distorted visual experience whereby everything looks too small.

Therefore I am changing my opinion and I think we should automatically apply a 1.25x scale factor for these screens, . This would mean 125% for 1080p and 250% for 4K with screens in the 13-14" size range. 1080p and 4K are only really right for a 15.6" screen IMO.

ngraham updated the task description. (Show Details)Jul 9 2020, 4:54 PM
ngraham updated the task description. (Show Details)Jul 9 2020, 4:56 PM

This might be relevant: https://www.w3.org/TR/css-values-4/#absolute-lengths

The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm’s length. For a nominal arm’s length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm’s length, 1px thus corresponds to about 0.26 mm (1/96 inch).

Has been that way since Firefox 3.6 -> 4 switch if I remember correctly.
And web pages work on a variety of devices.

It aligns with the information in the original post.

ngraham updated the task description. (Show Details)Jul 11 2020, 4:35 AM
hein added a subscriber: hein.Jul 11 2020, 10:24 PM

Overall this makes quite good sense, and I applaud the effort. Couple of thoughts and notes:

  • Picking a sensible default scale factor for certain brackets in the display spectrum (i.e. 125%) should be the preferred way to go.
  • Tuning the font DPI to fine-grain more is a good second option - but we shouldn't do tricks with the pt values.
  • If you want to go really deep into doing reference math on this, you start defining pixels as degrees of arc ... :-)
  • Historical note: I don't think X11 ever had a default value of 96 itself ... but lots of distros used a variety of techniques to set one up, mostly to match Windows (which inherited it from elsewhere as well to be fair).
ngraham updated the task description. (Show Details)Jan 12 2021, 1:20 AM
ghost65 added a subscriber: ghost65.EditedFeb 13 2022, 10:54 AM

late to the party question.
is this issue still pursued?
when I got my new laptop I noticed that it the new archlinux install UIs seemed too small.
my last laptop was an old 15.6" 1366x768 .
my new one is a 13.99' 1080
after a lot of changes I arrived at using 150% scale in kde display setting.
but I still have a lot of questions.

it this an X issue only? because I tried plasma on wayland and the issue is there too.
but trying scaling on wayland has more issues than X.

I see that there is two options in each wayland and x situation:
one is scaling and the other is resolution reduction.

resolution reduction seems to work the same for both wayland and X (minus first time crash in X) but screen becomes kind of blurry I think (or some apps do) .

but scaling works way different in them. in X the scaling gets applied to kde apps like dolphin very nicely and also I dont lose resolution.
so a picture viewer showing a 1080p picture in normal size, correctly covers the entire screen.
firefox seems to get a 150% scale which causes it to see a 720p screen (which can be tested by javascript ) so the tab bar and text are readable . but some apps like amuled and telegram don't get zoomed at all it seems.

now wayland:

when I use scaling in wayland in setting it also seems that my resolution is also lowered ( to 720p) which is weird.
this is different than actually lowering the resolution to 720p in wayland.
when I use mpv movie player in wayland the lowering the resolution causes it to show in its info:
scaled resolution : 1280x720p
but when I use scaling it says
scaled resolution : 2560x1440p
it seems that in the scaling situation mpv sees a 1440p screen. (which is twice 720p)

a picture viewer showing a 720p picture in normal size, covers the entire screen. and a 1080p picture in original size would spill out of screen.

amule and telegram get zoomed and readable in wayland but it seems that it is because the whole screen in now a 720p screen.

is this a bug?
why wayland lowers the resolution in the scaling but x doesn't?
is one of them the correct and the other wrong?

I dont think the wayland way is the correct way because not only user loses resolution but also this would cause slight blurring in thing like movies and pictures because the player will try to show a 720p picture on a 1080 pixel screen which because they are fractional scale and not whole number scale the 1080pixel picture would have to get distorted to be rendered to a virtual 720p screen and again to get to 1080p physical screen.

some more info:

I dont knwo why but the xdpyinfo command shows the wrong dimention for my laptop when I use default everything (new clean install)
xdpyinfo | grep -B 2 resolution
screen #0:

dimensions:    1920x1080 pixels (508x285 millimeters)
resolution:    96x96 dots per inch

but my laptop is
xrandr | grep -w connected
eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x 174mm

the xrandr command sees that.

maybe some of my issues is that?
if kde (or gnome even) see my screen as 1920x1080 pixels (508x285 millimeters)96x96 DPI
then shouldn't that be fixed first ?

is this normal?
do you guys also get this if you reset scale and dpi to default and re-login and test with those commands?

if we want to fix the UI size issue we should first fix underlying issues then build on that right?
but all this is on X and I have no idea how to see what wayland sees as physical screen size.
but my guess is the same as X.

This proposal will be implemented if and when https://invent.kde.org/plasma/kscreen/-/merge_requests/152 is merged!

ngraham closed this task as Resolved.Jan 11 2024, 6:36 PM
ngraham moved this task from Backlog/Planned to Done on the VDG board.

That was merged, and this is basically done in Plasma 6 now.