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 720502 - 1.5 scaling-factor
1.5 scaling-factor
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: gtk-bugs
gtk-bugs
: 773910 (view as bug list)
Depends on:
Blocks: 725118
 
 
Reported: 2013-12-15 19:52 UTC by Fedor Nikolaev
Modified: 2017-12-15 14:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
available in gnome 3.26 (31.58 KB, image/png)
2017-10-11 16:34 UTC, Matthias Clasen
Details

Description Fedor Nikolaev 2013-12-15 19:52:34 UTC
I want ability to set scaling-factor to 1.5 or other float value near it. With default value of 1 everything is too small, because my laptop (Asus Zenbook UX21a) has 190 dpi. When setting it to 2 text become readable but it looks too big, some windows don't get into screen size etc.
Comment 1 André Klapper 2013-12-16 18:44:37 UTC
Which gtk+ version does this refer to?
Comment 2 Fedor Nikolaev 2013-12-17 08:44:53 UTC
3.10. I talk about HiDPI support that Alexander Larsson wrote.
Comment 3 Arun Raghavan 2014-01-11 05:21:10 UTC
I have the same problem here. I understand why only integer scaling is supported at the moment (fitting the scaled version to the actual pixel grid), but we're going to end up hitting this problem across a _lot_ of laptops in days to come.

For example, I have a 1920x1080 display on a 13.3" display (Sony Vaio Pro 13). The DPI is 165 so a scaling factor of 2 looks too huge, and unscaled, everything is just barely usable.

Thoughts on how to fix this would be useful.
Comment 4 Brion Vibber 2014-02-25 19:28:08 UTC
As a nasty hack, you can set the desktop scaling to 2x but adjust the screen resolution to higher-than-native and let the display scale it partway back down.

This works in Fedora 20 live CD on my Dell XPS 13 'Sputnik 2' (1920x1080 13" screen):

$ gsettings set org.gnome.desktop.interface scaling-factor 2
$ xrandr --output eDP1 --scale-from 2560x1440 --panning 2560x1440

(The "--panning" option is needed or the mouse cursor seems to get stuck within the 1920x1080 boundary.)


The obvious disadvantage is that the output is not quite as crisp as if it were natively rendering at ~1.5x, and it'll use more memory etc.
Comment 5 Timur Kristóf 2014-05-23 13:03:09 UTC
Same here: 1920×1080 on 13.3" (Asus Zenbook)

As a "workaround" you can just increase the font size (which allows fractional values) which is not as good as scaling but will make things readable.

I +1 the idea of allowing fractional values for HiDPI mode!
Comment 6 Daniel Svensson 2015-05-18 09:05:02 UTC
Same for ThinkPad X1 Carbon, 1440p @ ~13", doubling all the UI is a trainwreck. Currently running no scaling, and just larger font DPI. Not optimal since it leaves icons way too small in some cases, but it's better than having no space due to everything being too large.
Comment 7 Emmanuele Bassi (:ebassi) 2015-05-18 09:14:25 UTC
We cannot use fractional scaling factors: windowing system surfaces cannot have a fractional size, and graphic assets would look terrible unless you shipped them pre-rendered at the right scaling factor, which you cannot do if you support a whole set of fractional values — and no: SVG is not a viable solution.

What we could do is take a page out of the MacOS rule book, and do a scale up by an integer factor, and then scale down while still leaving everything pixel aligned — e.g. scale up by 2x and then scale down by 1.5x; or scale up by a factor of 3x and then scale down by a factor of 2x. Sadly, we cannot really do that without Wayland, because we need input transformations, and we need to be able to perform this kind of scaling with the assistance of the display server.

This would also dovetail with per-output scaling factors, which depends on Wayland as well.
Comment 8 fulminemizzega 2016-09-14 15:09:19 UTC
(In reply to Emmanuele Bassi (:ebassi) from comment #7)
> [...] 
> What we could do is take a page out of the MacOS rule book, and do a scale
> up by an integer factor, and then scale down while still leaving everything
> pixel aligned — e.g. scale up by 2x and then scale down by 1.5x; or scale up
> by a factor of 3x and then scale down by a factor of 2x. Sadly, we cannot
> really do that without Wayland, because we need input transformations, and
> we need to be able to perform this kind of scaling with the assistance of
> the display server.
> [...]
Can any of what you've said be done now with wayland? My laptop has 15" 1080p display and I do need to scale everything up a little as I do on windows. With X11 I can use xrandr, but with Wayland what's available to scale down after scaling up with gnome?
Thanks for the great work you guys are pulling off with Gnome, it never stops getting better.
Comment 9 Emmanuele Bassi (:ebassi) 2016-11-27 12:46:20 UTC
*** Bug 773910 has been marked as a duplicate of this bug. ***
Comment 10 Emmanuele Bassi (:ebassi) 2016-11-27 12:49:46 UTC
(In reply to fulminemizzega from comment #8)
> (In reply to Emmanuele Bassi (:ebassi) from comment #7)
> > [...] 
> > What we could do is take a page out of the MacOS rule book, and do a scale
> > up by an integer factor, and then scale down while still leaving everything
> > pixel aligned — e.g. scale up by 2x and then scale down by 1.5x; or scale up
> > by a factor of 3x and then scale down by a factor of 2x. Sadly, we cannot
> > really do that without Wayland, because we need input transformations, and
> > we need to be able to perform this kind of scaling with the assistance of
> > the display server.
> > [...]
> Can any of what you've said be done now with wayland?

Not right now: we need the help of the compositor to implement this. The toolkit can scale to 3x its own surfaces, but the compositor must then scale down by a factor of 2x everything else - including input. This, additionally, requires treating each monitor as a different output surface.

Hopefully this new functionality will happen soon, since a lot of work has gone into Mutter/GNOME Shell in order to prepare for this.
Comment 11 Mingye Wang 2016-12-09 15:57:27 UTC
Contrary to a "scale factor" record, MS Windows uses a DPI record which itself is an integer. Recording the DPI instead of the factor gives Windows users some fine-grained +-1/96x control. KDE seems able work with such integers returned from X too.

(I am not exactly sure about how rounding works with these factors, but apparently someone elsewhere made it work...)
Comment 12 Adam Williamson 2016-12-09 16:15:28 UTC
KDE is just setting the X DPI. GNOME can do that too: you can set the 'text scaling factor' (in gnome-tweak-tool) to any number with two digits of floating point precision. The calculation for a 'DPI' value is trivial: 1.00 == 96dpi and it's purely proportional. Want 126dpi? Set text scaling factor 1.31.

The limitation of that is that it only affects text, and interface elements whose size is determined by the text they contain. It doesn't affect image-based things. It's not true interface scaling.

We don't know for sure exactly what kind of interface scaling Windows does when you change the equivalent setting.
Comment 13 nw9165-3201 2017-01-14 19:05:27 UTC
Any update on this one?
Comment 14 Matthias Clasen 2017-02-15 23:03:49 UTC
*** Bug 773910 has been marked as a duplicate of this bug. ***
Comment 15 Matthias Clasen 2017-10-11 16:34:16 UTC
Created attachment 361341 [details]
available in gnome 3.26
Comment 16 Wolfgang Rosenauer 2017-12-15 12:01:06 UTC
I cannot see those options in 3.26.2 (Xorg)?
Comment 17 Emmanuele Bassi (:ebassi) 2017-12-15 12:05:35 UTC
(In reply to Wolfgang Rosenauer from comment #16)
> I cannot see those options in 3.26.2 (Xorg)?

X cannot support this kind of scaling; you need Wayland, and you need to enable the experimental scaling support in the Mutter settings.