GNOME Bugzilla – Bug 773910
Improve non-integer scaling capabilities
Last modified: 2017-09-09 09:06:49 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) 2) Font scaling 'Window scaling', which scales all interface elements, is only implemented at integer multiples. i.e. you can't set a 'window scaling factor' of 1.5 (or 1.25, or 1.678234). 'Font scaling' is implemented with very fine granularity (you *can* set a 'font scaling factor' of 1.678234), but it only affects certain things: fonts, obviously, and (I think) interface elements whose size is related to the text they contain (e.g. buttons with text labels). I don't honestly have all the technical details perfectly nailed down, either in exactly what font scaling effects, or *exactly* what other OSes implement. But I've read a few things about this lately, and had several discussions on various lists, and it seems that both OS X (macOS) and Windows 10 have scaling implementations that are at least somewhat more sophisticated than GTK+'s / GNOME's. Both Windows 10 and macOS offer configuration settings in their equivalent of 'Display' that allow the user to configure scaling at finer than integer granularity - this is discussed in more detail in https://bugzilla.gnome.org/show_bug.cgi?id=773909 (which proposes adding such a setting to GNOME). In terms of how they actually *work*, I've been told that the Windows 10 setting does scale all interface elements by the amount requested. It provides, apparently, some kind of mechanism whereby applications can provide variants of graphical elements at the appropriate sizes, and if they don't, it simply zooms whatever element the app provides. Again I really don't know a lot about this, but that's how it was described to me. Apple's official documentation still basically reads as if only scaling factors of 1.0 and 2.0 are possible: https://developer.apple.com/library/content/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Introduction/Introduction.html but that seems to be from 2012. I'm not sure if an update is available somewhere. Various references suggest that the way Apple handles non-integer scaling is to first scale to 2x - which is all software has to care about - and then just before output to the actual display, scale the entire rendered visual back down using the GPU. e.g.: http://forums.macrumors.com/threads/can-someone-explain-to-me-how-resolution-scaling-works.1868976/#post-21028676 , http://www.anandtech.com/show/6023/the-nextgen-macbook-pro-with-retina-display-review/6 : "If you select the 1680 x 1050 or 1920 x 1200 scaling modes, Apple actually renders the desktop at 2x the selected resolution (3360 x 2100 or 3840 x 2400, respectively), scales up the text and UI elements accordingly so they aren’t super tiny (backing scale factor = 2.0), and downscales the final image to fit on the 2880 x 1800 panel." There's also some mention on the anandtech page that vector graphics, as well as fonts, are scaled natively to whatever the target scaling factor is, which would make sense, I guess.
https://bugzilla.gnome.org/show_bug.cgi?id=773909 has some data on why non-integer scaling is now much more important than it used to be (basically, there are now many many displays on the mass market which don't look good at either 1.0 or 2.0 scaling), which should answer the question "but why should we bother"? Obviously if, as that bug proposes, we're going to provide an interface for non-integer scaling, and thus effectively make it an expected thing for people to do, we should make it work as well as possible.
Any update on this one? Could you please allow to set floating values as well? Being restricted to integer values, i.e. 1, 2, 3 etc. makes this unusable on a lot of monitors.
Thanks for the detailed description. There's an overall discussion on adding 1.5x scaling factor for windowing system resources (i.e. not text) between 1x and 2x, which is pretty much what macOS allows. Good description of this bug notwithstanding, I'm going to mark it as a duplicate. *** This bug has been marked as a duplicate of bug 773909 ***
*** This bug has been marked as a duplicate of bug 720502 ***
I do not agree that this is a duplicate. Simply adding a single extra mode is not going to be enough, and both Windows and OS X clearly offer more than just 1, 1.5 and 2, as you can see from the screenshots in #773909.
(In reply to Adam Williamson from comment #5) > I do not agree that this is a duplicate. Have you read bug 720502? > Simply adding a single extra mode > is not going to be enough, and both Windows and OS X clearly offer more than > just 1, 1.5 and 2, as you can see from the screenshots in #773909. Apple only allows integer scaling for windowing system resources: > The value of this property is 2.0 for high-resolution scaled > display modes, and 1.0 for all other cases. It's also a read-only value, because application developers are only supposed to read from it when computing sizing and asset loading. Non-integral factors are a combination of: * compositor downscaling (with input transformation to compensate) * text rendering with a different "resolution" But in the end, if you want to have grid-aligned pixels (and thus avoid blurry text and icons) and appropriate assets loaded for the screen density, you need an integer scaling factor in the toolkit. From a GTK+ perspective, all of this is available today. The downscaling can only be applied from the compositor, and only when running under Wayland, because of the input transformation, as well as offering different scaling factors depending on the output monitor. In both cases, GTK+ already exposes all the necessary knobs to perform upscaling of windowing surfaces and change of text rendering resolution; if you want a UI for that, you'll have to ask for one inside gnome-control-center. Ideally, you could choose between: 1 --- 1.5 --- 2 | | | on a scale, depending on how dense you want your UI to be. Obviously, there's nothing GTK+ can do for applications that do not use GTK+ >= 3.x; GTK+ 2.x applications, like non-GTK+ applications, will need their own mechanisms to handle these cases. The compositor could help by scaling up all the windows, but then you'd get blurry icons. In any case this is not something GTK+ can fix.
Well, please do re-assign wherever it's more appropriate.
(In reply to Emmanuele Bassi (:ebassi) from comment #6) > In both cases, GTK+ already exposes all the necessary knobs to perform > upscaling of windowing surfaces and change of text rendering resolution; if > you want a UI for that, you'll have to ask for one inside > gnome-control-center. Ideally, you could choose between: > > 1 --- 1.5 --- 2 > | | | > > on a scale, depending on how dense you want your UI to be. Could you please re-assign this to gnome-control-center then: https://bugzilla.gnome.org/page.cgi?id=browse.html&product=gnome-control-center ?
one bug for fractional scaling is enough, when there is not even anything to do in gtk *** This bug has been marked as a duplicate of bug 720502 ***