GNOME Bugzilla – Bug 773909
Allow scaling configuration in Display (or Fonts)
Last modified: 2021-06-09 16:30:16 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.
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.
Created attachment 339063 [details] OS X / macOS interface (taken from https://support.apple.com/en-ca/HT202471 )
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
*** Bug 773910 has been marked as a duplicate of this bug. ***
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"
Any update on this one?
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.
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.