After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 773909 - Allow scaling configuration in Display (or Fonts)
Allow scaling configuration in Display (or Fonts)
Status: RESOLVED OBSOLETE
Product: gnome-control-center
Classification: Core
Component: Display
git master
Other Linux
: Normal normal
: ---
Assigned To: Debarshi Ray
Control-Center Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-11-03 18:40 UTC by Adam Williamson
Modified: 2021-06-09 16:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Windows 10 interface (taken from https://www.thurrott.com/windows/windows-10/4597/windows-10-feature-focus-display-scaling ) (24.53 KB, image/jpeg)
2016-11-03 18:46 UTC, Adam Williamson
Details
OS X / macOS interface (taken from https://support.apple.com/en-ca/HT202471 ) (440.59 KB, image/png)
2016-11-03 18:49 UTC, Adam Williamson
Details

Description Adam Williamson 2016-11-03 18:40:52 UTC
At present, GNOME has two distinct types of scaling for displays which don't look good at the default 96dpi setting:

1) 'Window scaling' (hidpi scaling) - auto-detected, manually configurable (in integer jumps only) only from dconf and tweak-tool

2) Font scaling - granular control available only from tweak-tool, and a toggle between 1.0 and 1.25 in Universal Access as 'Large Text'

Having scaling configuration available only as an a11y setting made sense a few years ago, when the 96dpi consensus was still strong. But these days it arguably isn't. There are more and more displays on the market, widely used by both the public and GNOME target audiences such as developers, that simply do not look good at 96dpi. There are two major, obvious categories:

* 12-14", 1920x1080 laptops (157-176dpi)
  * Entry-level 5th/6th/7th-gen Dell XPS 13
  * Some 2nd/3rd, all(?) 4th-gen Dell XPS 13
  * Dell Inspiron 13 7000
  * Dell Inspiron 13 5000
  * Lenovo Thinkpad 13 (some models)
  * Lenovo Thinkpad X (many models are 14" 1920x1080)
  * HP Elite (many 14" 1920x1080 models)
  * etc. etc.

* "4K" (~3840x2160) desktop monitors below 32" (31.5" = 140dpi, 28" = 157dpi, 24" = 184dpi)
  * LG 27UD68P-B (27")
  * LG 27UD58-B (27")
  * SAMSUNG U24E590D (23.6")
  * ViewSonic VP2780-4K (27")
  * ViewSonic VG2860MHL-4K (28")
  * Asus ROG PG27AQ (27")
  * Dell S2817Q (28")
  * ASUS PB287Q (28")
  * etc. etc.

None of these are exotic pieces of hardware. To find the laptops I just went to the major manufacturer sites and clicked around a bit, I found them all within 5 minutes, these are not expensive niche models, they are standard business and mid-tier models. Many are under $1000.

Similarly with the monitors, those are literally just the first half page of 4K monitors listed on Newegg, minus just a couple of >40" models (ooh, I want one of those). Many of them cost less than $500. The Samsung costs $320. If I'd kept on going, there are dozens more. These are almost commodity hardware now.

Point being: there are now many, many displays on the mass market where everything in GNOME will look tiny out of the box, yet the only setting which might ameliorate the problem is in Universal Access, where most people aren't going to look, especially if they don't think there's anything wrong with their eyesight.

So I propose there should be a display scaling setting in either Display or Fonts, where people are likely to look for it.

Furthermore, I propose it be more flexible than the current 'Large Text' setting. I'd say that just allowing a simple toggle between 1.0 and 1.25 scaling is not sufficient for the range of displays commonly available.

1.25 is probably OK for a 13.3" 1920x1080 laptop display (personally I use 1.3 on mine, but close enough) but it might not be enough at 12.5", especially for someone with less-than-perfect eyesight.

1.25 is *clearly* not going to be enough for a 23.6" 3840x2160 desktop display (which is only slightly below triggering the automatic hidpi scaling). In fairness these are probably the least popular 4K models, but still, they're out there and easily available.

1.25 is pretty weak for even 27" 3840x2160, which is 163dpi. 1.5 or even 1.75 would be a lot more comfortable there. And that *is* a fairly commonly purchased size, I believe.

The other major desktop OSes offer substantially more flexibility than GNOME here. I will attach screenshots of the Windows 10 and OS X / macOS UIs. Windows basically shows a slider which goes in .25 increments from (I believe) 1.0 to 2.0 (not sure about that top end, it may be higher). OS X / macOS shows either four or five little fake-screenshot-thumbnail things (a bit hard to describe) which give a kind of illustration of the effect of each setting on text and interface elements. I don't know precisely what actual scaling factor each of the either 4 or 5 settings applies. Apple says "Your Mac will show either four or five scaled resolution options depending on the model."

In terms of the implementation, given GNOME/GTK+'s current capabilities, I guess increments between integers should affect the font scaling factor, and when you hit an integer, the display scaling factor should be bumped and the font scaling factor reset to 1.

I'm not sure whether we want to revisit the question of auto-detection here, if we want to do it at all it should probably be a separate bug. But I think we should at least offer an appropriately powerful configuration interface in the expected place.

As for the Universal Access 'Large Text' setting, it could either remain as a simple 1.0 / 1.25 toggle and the Display setting could (I guess) override it (I dunno what the toggle should show if the Display slider was set to something other than 1.0 or 1.25...), or it could simply be replaced with a link to Display, I guess.
Comment 1 Adam Williamson 2016-11-03 18:46:58 UTC
Created attachment 339062 [details]
Windows 10 interface (taken from https://www.thurrott.com/windows/windows-10/4597/windows-10-feature-focus-display-scaling )

The Windows 10 interface. The article notes that the slider moves in .25 (25%) increments, and the '100%' text changes as you slide.
Comment 2 Adam Williamson 2016-11-03 18:49:33 UTC
Created attachment 339063 [details]
OS X / macOS interface (taken from https://support.apple.com/en-ca/HT202471 )
Comment 3 nw9165-3201 2016-11-27 11:53:40 UTC
gnome-tweak-tool already has such a setting, see following screenshot:

http://core0.staticworld.net/images/article/2015/04/tweak-tool-window-100580051-orig.png

But unfortunately it only allows to use integer values, which has been reported in:

https://bugzilla.gnome.org/show_bug.cgi?id=773910
Comment 4 Emmanuele Bassi (:ebassi) 2016-11-27 12:46:05 UTC
*** Bug 773910 has been marked as a duplicate of this bug. ***
Comment 5 Adam Williamson 2016-11-27 16:56:37 UTC
nw9165-3201: the bug description already talks about that. Right at the top. "1) 'Window scaling' (hidpi scaling) - auto-detected, manually configurable (in integer jumps only) only from dconf and tweak-tool"
Comment 6 nw9165-3201 2017-01-14 19:07:15 UTC
Any update on this one?
Comment 7 Allan Day 2017-02-06 16:02:50 UTC
Font scaling is rather crude. I'd sooner wait until we have a better way to scale the UI before adding it to the display settings.
Comment 8 André Klapper 2021-06-09 16:30:16 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new bug report at
  https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/

Thank you for your understanding and your help.