[opensuse-factory] Upcoming changes to HiDPI scaling in Qt
Hi, tl;dr section at the bottom. During Leap 15.0 development, a focus was on the experience with HiDPI (>96 pixels per inch) monitors. Some bugs got reported which indicated that there were some issues especially in mixed-DPI environments. While they generally work fine after some (extensive) manual configuration, the automatic configuration wasn't quite that good. Fixing this will also improve the experience during the installation (no manual configuration possible) and on desktops which don't have a UI to configure it. X was not designed for HiDPI and especially not mixed-DPI environments. It has only a single dpi specifier for the whole screen (spanning all monitors) and it is on all drivers, except the proprietary Nvidia driver, 96x96dpi. Each monitor geometry is available via XRandR though. Now Qt comes into play: It uses the screen DPI (so 96dpi) as global DPI and applies per-monitor scale factors on top. There is a font scale factor which is computed by (screen DPI)/(primary monitor DPI). If your primary monitor has 96dpi and your secondary 192dpi, it results in a 1x font scale and 1x/2x scale factors, as expected. If you set the 192dpi monitor as primary though, it gets ugly: The font scale is now 96/192 = 0.5x and 1x/2x scale factors mean that applications on either monitor are half of the expected size (1x on the primary and 0.5x on the secondary). This is reported upstream as https://bugreports.qt.io/browse/QTBUG-67928 The solution: Ignore the 96dpi which X reports by default and only use the monitor geometry as scale. The good: The font size on HiDPI and especially mixed-DPI environments is now scaled by default. The bad: You might unintentionally rely on the 96dpi X reports if you have a HiDPI monitor but keep applications unscaled. That requires manual configuration now. The ugly: If you have a primary monitor with != 96dpi, this is a behaviour change and results in changed appearance of applications. YaST for example uses bigger fonts, but the UI elements stay the same size. tl;dr: Look out for changes in application appearance and report any bugs. If you have a HiDPI system with custom configuration for DPI or scale, try to reset it to the defaults again and check whether it behaves as expected. You can revert to the old behaviour by setting "Xft.dpi: 96" (most configuration dialogs call it "Force font DPI") or by setting QT_FONT_DPI=96 in the environment. Cheers, Fabian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
пʼятниця, 29 червня 2018 р. 16:33:24 EEST Fabian Vogt написано:
X was not designed for HiDPI and especially not mixed-DPI environments. It has only a single dpi specifier for the whole screen (spanning all monitors) and it is on all drivers, except the proprietary Nvidia driver, 96x96dpi. Each monitor geometry is available via XRandR though. I'm using SDDM config:
[XDisplay] ServerArguments=-nolisten tcp -dpi 142 to explicitly set 142 DPI But still, X has no support of mixed DPI, and when my external monitor has about 96-100 DPI, it looks not good :(
This is reported upstream as https://bugreports.qt.io/browse/QTBUG-67928 IMHO, that should be fixed in X drivers in the first place, not Qt. Am I wrong?
You can revert to the old behaviour by setting "Xft.dpi: 96" (most configuration dialogs call it "Force font DPI") or by setting QT_FONT_DPI=96 in the environment. As for now, I forced to set "Xft.dpi: 142" for GTK apps, as they ignore X parameters and are forced to 96 DPI, unless Xft.dpi is set. And that is very bad. Especially, as GDK_SCALE couldn't be fractional and 2 is too big for me and 1 is too small. So how those changes will affect non-Qt apps, like GTK? If Xft.dpi isn't set they became broken. And if I'll set Xft.dpi how new behaviour would work?
-- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський
Mykola Krachkovsky composed on 2018-06-30 11:00 (UTC+0300):
Fabian Vogt composed:
You can revert to the old behaviour by setting "Xft.dpi: 96" (most configuration dialogs call it "Force font DPI") or by setting QT_FONT_DPI=96 in the environment.
As for now, I forced to set "Xft.dpi: 142" for GTK apps, as they ignore X parameters and are forced to 96 DPI, unless Xft.dpi is set.
If you are using only openSUSE, you shouldn't need to use Xft.dpi as your DPI configuration mechanism.[1] Not all apps respond to it. Overriding the server's disregard of EDID (via DisplaySize or xrandr or the NVidia driver's dpi xorg.conf parameter) should make all apps see the same server DPI.
And that is very bad. Especially, as GDK_SCALE couldn't be fractional and 2 is too big for me and 1 is too small.
This had to be expected at least as far back as GTK-3.0-1.0. Mozilla apps were suffering this years before .5 increments were implemented for them.
So how those changes will affect non-Qt apps, like GTK? If Xft.dpi isn't set they became broken. And if I'll set Xft.dpi how new behaviour would work?
Until it actually happens, maybe give a try to the non-Xft.dpi methodology? Maybe it need not affect you. BTW, font size gradations are often smoother the closer logical DPI is to a multiple of 12, best if a multiple of 24. Its possible you might enjoy a marginal improvement using 143 instead of 142. 144 is a mozilla breakpoint, so if you are a Firefox or TB user you might not be happy at the initial difference and find it desirable to deviate from their default layout.css.devPixelsPerPx setting. http://fm.no-ip.com/Auth/Font/font-rounding.html might be of use in evaluating the impact(s). [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1022830 -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
субота, 30 червня 2018 р. 12:38:28 EEST Felix Miata написано:
If you are using only openSUSE, you shouldn't need to use Xft.dpi as your DPI configuration mechanism.[1] Not all apps respond to it. Overriding the server's disregard of EDID (via DisplaySize or xrandr or the NVidia driver's dpi xorg.conf parameter) should make all apps see the same server DPI. Wow, thanks! I've made that a long time ago, when that was problem in GTK, haven't checked that after that. Nice to know it's is fixed in openSUSE. One hack removed.
This had to be expected at least as far back as GTK-3.0-1.0. Mozilla apps were suffering this years before .5 increments were implemented for them. Hmm. I might didn't get it. GDK_SCALE=1.5 is ignored by any application I've tested, should it work? Firefox doesn't need GDK_SCALE (though support it, but again, only integral numbers, GDK_SCALE=1.5 loooks exactly like GDK_SCALE=1)
BTW, font size gradations are often smoother the closer logical DPI is to a multiple of 12, best if a multiple of 24. Its possible you might enjoy a marginal improvement using 143 instead of 142. 144 is a mozilla breakpoint, so if you are a Firefox or TB user you might not be happy at the initial Yeah, actually, Xft.dpi was set to 144 because of Firefox, so removed it and set in sddm to 144.
-- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський
Hi, Am Samstag, 30. Juni 2018, 10:00:18 CEST schrieb Mykola Krachkovsky:
пʼÑÑниÑÑ, 29 ÑеÑÐ²Ð½Ñ 2018 Ñ. 16:33:24 EEST Fabian Vogt напиÑано:
X was not designed for HiDPI and especially not mixed-DPI environments. It has only a single dpi specifier for the whole screen (spanning all monitors) and it is on all drivers, except the proprietary Nvidia driver, 96x96dpi. Each monitor geometry is available via XRandR though. I'm using SDDM config:
[XDisplay] ServerArguments=-nolisten tcp -dpi 142
to explicitly set 142 DPI
But still, X has no support of mixed DPI, and when my external monitor has about 96-100 DPI, it looks not good :(
Did you also set EnableHiDPI=true? As you already set -dpi manually, the Qt patch which will be added won't have an effect here, sorry. However, once the Qt changes landed we can make EnableHiDPI=true in sddm the default, as this is the only reason it's not the case already.
This is reported upstream as https://bugreports.qt.io/browse/QTBUG-67928 IMHO, that should be fixed in X drivers in the first place, not Qt. Am I wrong?
Not really, but it would also not fix it as the interpretation of that value depends on the toolkit. If you have 96/192 dpi monitors, should X report 96 or 192 as global dpi? Or even 144 as the average? Neither is correct, really.
You can revert to the old behaviour by setting "Xft.dpi: 96" (most configuration dialogs call it "Force font DPI") or by setting QT_FONT_DPI=96 in the environment. As for now, I forced to set "Xft.dpi: 142" for GTK apps, as they ignore X parameters and are forced to 96 DPI, unless Xft.dpi is set. And that is very bad. Especially, as GDK_SCALE couldn't be fractional and 2 is too big for me and 1 is too small. So how those changes will affect non-Qt apps, like GTK? If Xft.dpi isn't set they became broken. And if I'll set Xft.dpi how new behaviour would work?
If you want fonts to be drawn at 142dpi on your primary monitor, setting Xft.dpi is correct. Depending how you want Qt applications to scale on the secondary one, you can set QT_SCREEN_SCALE_FACTORS to fractional values as well (e.g. "1.5;1"). You might need to set QT_AUTO_SCREEN_SCALE_FACTOR=0 as well. For GTK, you can play around with GDK_DPI_SCALE. To get a 1.5 scale GDK_SCALE=2 GDK_DPI_SCALE=0.75 should work. GTK applications do not support mixed-DPI on X11 at all, AFAIK. Cheers, Fabian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, субота, 30 червня 2018 р. 13:00:51 EEST Fabian Vogt написано:
Did you also set EnableHiDPI=true? No, will try it.
However, once the Qt changes landed we can make EnableHiDPI=true in sddm the default, as this is the only reason it's not the case already. So, basically, this patch would mean no need for a hack with manual DPI set in configs for Qt apps. Thanks.
Depending how you want Qt applications to scale on the secondary one, you can set QT_SCREEN_SCALE_FACTORS to fractional values as well (e.g. "1.5;1"). You might need to set QT_AUTO_SCREEN_SCALE_FACTOR=0 as well. The problem with QT_SCREEN_SCALE_FACTORS is that at 1.5 a lot of stuff looks not very good. Icons are aliased, some lines are 1px and some 2px. I prefer to set text DPI to native DPI and increase icons size without scaling, then both icons and other stuff looks fine and readable.
For GTK, you can play around with GDK_DPI_SCALE. To get a 1.5 scale GDK_SCALE=2 GDK_DPI_SCALE=0.75 should work. GTK applications do not support mixed-DPI on X11 at all, AFAIK. GDK_DPI_SCALE — nice to know, thanks. But as for Inkscape (gtk2) only old way is possible, right?
-- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський
On sobota 30. června 2018 10:00:18 CEST Mykola Krachkovsky wrote:
пʼятниця, 29 червня 2018 р. 16:33:24 EEST Fabian Vogt написано:
This is reported upstream as https://bugreports.qt.io/browse/QTBUG-67928
IMHO, that should be fixed in X drivers in the first place, not Qt. Am I wrong?
There is really nothing to fix, X server provides the DPI information in two ways: 1) One global DPI value. This is deprecated (for many years) and should not be used anymore. It can not be removed because of backward compatibility of the protocol. It is fixed to 96 DPI for legacy applications. 2) Resolution + physical size (=> DPI) is reported for every monitor using RandR. This provides accurate information even in mixed-DPI situation. Unlike the other value it can also change dynamically when the monitor setup changes. This should be used by today's applications. The issue is that some applications need a single DPI value for something and so they use 1) and then complain that it is incorrectly set to 96. There were many requests to use change it to some more realistic default, e.g. DPI of the primary monitor or average of all monitor DPIs... But X developers have strong opinion that since the value is deprecated, use of it should be discouraged so it will remain at 96 DPI. The applications should instead examine DPI of all connected monitors and calculate the single value in a way that makes sense for their use case - perhaps calculate average to look ok-ish on all monitors, or choose the maximum DPI and scale down when placed on other monitors, or resize to the real DPI of the current monitor when they are moved... There are many options and it is up to the application/framework to decide. The nvidia proprietary driver is rogue and overwrites the 1) value when loaded. I am not sure how it calculates the single value, I think it copies the one from primary monitor. Qt is now switching from using 1) and 2) to using only 2), which is great! Thank you Fabian for doing this work. Michal Srb -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
понеділок, 2 липня 2018 р. 14:19:24 EEST Michal Srb написано:
But X developers have strong opinion that since the value is deprecated, use of it should be discouraged so it will remain at 96 DPI. Yeah, I see a reason behind that as it deprecated. But there are a lot of applications that doesn't know about that, mostly gtk2 like Inkscape, GIMP. While I don't use GIMP a lot, I use Inkscape often and at 96 it looks too small.
There are many options and it is up to the application/framework to decide. In perfect world — yes. But IMHO, it's better to remove global DPI at all, this least would force developers of toolkits like gtk2 to fix it in a proper way or application developers to ditch unsupported toolkits. Or global DPI it to primary screen to make that old-style applications at least readable.
Qt is now switching from using 1) and 2) to using only 2), which is great! Thank you Fabian for doing this work. Yes, that's good.
-- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський
On pondělí 2. července 2018 15:25:31 CEST Mykola Krachkovsky wrote:
понеділок, 2 липня 2018 р. 14:19:24 EEST Michal Srb написано:
But X developers have strong opinion that since the value is deprecated, use of it should be discouraged so it will remain at 96 DPI.
Yeah, I see a reason behind that as it deprecated. But there are a lot of applications that doesn't know about that, mostly gtk2 like Inkscape, GIMP. While I don't use GIMP a lot, I use Inkscape often and at 96 it looks too small.
At least there is still a way to change the value manually for these cases.
There are many options and it is up to the application/framework to decide.
In perfect world — yes. But IMHO, it's better to remove global DPI at all, this least would force developers of toolkits like gtk2 to fix it in a proper way or application developers to ditch unsupported toolkits. Or global DPI it to primary screen to make that old-style applications at least readable.
The value (actually the physical dimensions of screen in mm) are part of the very first message sent from X server to X client. So there is no way to remove it without breaking every X client in existence. It could be set to something stupid, like 0, but I think that would be too drastic. For comparison, Wayland does not have such single value from start. So all frameworks had to learn to deal with it from beginning. If you run application that uses some old framework, it will proxy thru Xwayland and get the 96 DPI too. In addition Wayland can scale windows up on HiDPI displays, but scaled windows are blurry and you loose the advantage of HiDPI. So frameworks are encouraged to scale themselves instead and render in the native resolution. They could do the same under X. If they would, HiDPI and mixed-DPI would work just as good in X as in Wayland. Michal Srb -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Fabian Vogt composed on 2018-06-29 15:33 (UTC+0200):
Some bugs got reported which indicated that there were some issues especially in mixed-DPI environments. While they generally work fine after some (extensive) manual configuration, the automatic configuration wasn't quite that good.
While the server with access to valid EDID does correctly use display dimensions to calculate DPI, automatic DPI _configuration_ by the _server_ this way has been disallowed for well over a decade: https://bugs.freedesktop.org/show_bug.cgi?id=23705 Allowing automatic calculation was requested over 6 years ago, but has not been acted upon: https://bugs.freedesktop.org/show_bug.cgi?id=41115 DisplaySize in xorg.conf, and intervention by xrandr, have been able to make semi-automatic DPI configuration possible by enforcing the display dimensions otherwise ignored by the server. Applications can choose not to honor server DPI, looking instead to the Xresource Xft.dpi. Xft.dpi is the method by which KDE3, Plasma, TDE and some other DEs force DPI, while Xft.dpi is the knob Gnome uses to "scale". 3 years ago GTK3 chose to force to 96 in the absence of Xft.dpi having been set explicitly. Consequences of Xft.dpi forcing to 96 created predictable problems. Request was made to revert, and denied: https://bugzilla.gnome.org/show_bug.cgi?id=757142 openSUSE (thanks to Fabian!) rejected the upstream denial and reverted: https://bugzilla.opensuse.org/show_bug.cgi?id=1022830
Fixing this will also improve the experience during the installation (no manual configuration possible) and on desktops which don't have a UI to configure it. ...
'Tis a mess. ...
Because of the considerations I've above stated I doubt the mess will be improved by it. IMO it will little but increase the complication. We can only hope otherwise. Time will tell. Maybe this is a (the?) problem Wayland is destined to solve. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Am Samstag, 30. Juni 2018, 11:08:26 CEST schrieb Felix Miata:
Fabian Vogt composed on 2018-06-29 15:33 (UTC+0200):
Some bugs got reported which indicated that there were some issues especially in mixed-DPI environments. While they generally work fine after some (extensive) manual configuration, the automatic configuration wasn't quite that good.
While the server with access to valid EDID does correctly use display dimensions to calculate DPI, automatic DPI _configuration_ by the _server_ this way has been disallowed for well over a decade: https://bugs.freedesktop.org/show_bug.cgi?id=23705
Allowing automatic calculation was requested over 6 years ago, but has not been acted upon: https://bugs.freedesktop.org/show_bug.cgi?id=41115
DisplaySize in xorg.conf, and intervention by xrandr, have been able to make semi-automatic DPI configuration possible by enforcing the display dimensions otherwise ignored by the server. Applications can choose not to honor server DPI, looking instead to the Xresource Xft.dpi.
Yes, that's how Qt does it currently: $QT_FONT_DPI -> Xft.dpi -> X screen DPI The patch changes it to: $QT_FONT_DPI -> Xft.dpi -> XRandR DPI -> X screen DPI
Xft.dpi is the method by which KDE3, Plasma, TDE and some other DEs force DPI, while Xft.dpi is the knob Gnome uses to "scale".
Which is not entirely wrong - it's the only way to make HiDPI-unaware applications (like xterm) usable on HiDPI monitors.
3 years ago GTK3 chose to force to 96 in the absence of Xft.dpi having been set explicitly. Consequences of Xft.dpi forcing to 96 created predictable problems. Request was made to revert, and denied: https://bugzilla.gnome.org/show_bug.cgi?id=757142 openSUSE (thanks to Fabian!) rejected the upstream denial and reverted: https://bugzilla.opensuse.org/show_bug.cgi?id=1022830
Fixing this will also improve the experience during the installation (no manual configuration possible) and on desktops which don't have a UI to configure it. ...
'Tis a mess.
With this patch hopefully only if the automatic detection fails.
...
Because of the considerations I've above stated I doubt the mess will be improved by it. IMO it will little but increase the complication. We can only hope otherwise. Time will tell. Maybe this is a (the?) problem Wayland is destined to solve.
Almost. It started off as a good attempt, as wl_output got a "scale" property. This is sent by the compositor to the clients, so it's entirely up to the compositor how to set that. There is no separate configuration for font scale, that's up to the clients/toolkits. The issue with this is that the "scale" property is only an integer, so does not allow fractional scaling. It also doesn't support separate DPI for horizontal and vertical dimensions. xdg_output fixes this, as it reports its size both in physical and logical pixels. It's now up to the toolkits to handle this information in a sane way. xdg_output is AFAIK not stable yet, so it will take some time to reach us. So currently scaling with Wayland is actually worse than with X11 :-/ Cheers, Fabian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, On 06/29/2018, 03:33 PM, Fabian Vogt wrote:
During Leap 15.0 development, a focus was on the experience with HiDPI (>96 pixels per inch) monitors.
If you mean upcoming, does it mean that it is in factory/TW by now? Or is it only about Leap 15?
Look out for changes in application appearance and report any bugs. If you have a HiDPI system with custom configuration for DPI or scale, try to reset it to the defaults again and check whether it behaves as expected.
I would love to see some nice multi-dpi support (normal-dpi + hi-dpi connected at once here). I did some config fiddling without any good results and I do not remember how and what. How do I perform the reset? thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Am Dienstag, 3. Juli 2018, 08:48:39 CEST schrieb Jiri Slaby:
Hi,
On 06/29/2018, 03:33 PM, Fabian Vogt wrote:
During Leap 15.0 development, a focus was on the experience with HiDPI (>96 pixels per inch) monitors.
If you mean upcoming, does it mean that it is in factory/TW by now? Or is it only about Leap 15?
It's not in TW just yet - before I submit it I'll give it a final test on HiDPI hardware. I only tested the two patches (physical DPI as logical DPI and sanitation of physical dimensions in the EDID) separately but not together yet. If it turns out to work well for TW users, it'll be part of 15.1.
Look out for changes in application appearance and report any bugs. If you have a HiDPI system with custom configuration for DPI or scale, try to reset it to the defaults again and check whether it behaves as expected.
I would love to see some nice multi-dpi support (normal-dpi + hi-dpi connected at once here).
You might be interested in https://phabricator.kde.org/D12405.
I did some config fiddling without any good results and I do not remember how and what. How do I perform the reset?
In the Fonts KCM, uncheck "Force DPI for fonts". It should take effect immediately for newly started applications. Cheers, Fabian
thanks,
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
Fabian Vogt -
Felix Miata -
Jiri Slaby -
Michal Srb -
Mykola Krachkovsky