Bug 415421 - [hidpi] Inconsistent font size with certain apps such as Kate, KWrite, Konsole
Summary: [hidpi] Inconsistent font size with certain apps such as Kate, KWrite, Konsole
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: general (show other bugs)
Version: master
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: 1.0
Assignee: David Edmundson
URL: https://codereview.qt-project.org/c/q...
Keywords:
: 416014 416124 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-12-21 01:55 UTC by Andrew Udvare
Modified: 2020-04-18 09:25 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.18.0


Attachments
Dolphin vs a Gtk+ app rendering (837.30 KB, image/png)
2019-12-21 01:55 UTC, Andrew Udvare
Details
System Settings rendering correctly (261.33 KB, image/png)
2019-12-21 01:56 UTC, Andrew Udvare
Details
Konsole displaying incorrectly (597.08 KB, image/png)
2019-12-21 01:57 UTC, Andrew Udvare
Details
New user screenshot (64.24 KB, image/png)
2019-12-21 02:17 UTC, Andrew Udvare
Details
VirtualBox screenshot (411.81 KB, image/png)
2020-01-02 06:03 UTC, Andrew Udvare
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Udvare 2019-12-21 01:55:27 UTC
Created attachment 124632 [details]
Dolphin vs a Gtk+ app rendering

SUMMARY

Certain apps are rendering font sizes too large in comparison to others. This applies to:

* Dolphin
* Kate
* KWrite
* Konsole

The font sizes are about 25% larger than expected.

System Settings and just about every other app I have including Chromium run at the correct size.

I am attaching screenshots for reference. The first is a Gtk+ app vs Dolphin, where the Gtk+ app is showing the correct scale. The second is System Settings which is rendering correctly with the current settings.

STEPS TO REPRODUCE
1. Set scale factor to 1.5
2. Log out and log back in
3. Run Kate

OBSERVED RESULT

Kate is running with correct size icons (I think) but a 25% larger font than expected.

EXPECTED RESULT

Kate should have normal size fonts as other apps (like System Settings) do.


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: Gentoo, 5.17.4
(available in About System)
KDE Plasma Version: 5.17.4
KDE Frameworks Version: 5.65.0
Qt Version: 5.14.0

ADDITIONAL INFORMATION
Recently updated to latest versions available of Qt, Plasma, etc on Gentoo Portage.

This was not happening in a prior version.

I do not have forced font DPI enabled nor a DPI setting in ~/.Xresources.
Comment 1 Andrew Udvare 2019-12-21 01:56:15 UTC
Created attachment 124633 [details]
System Settings rendering correctly
Comment 2 Andrew Udvare 2019-12-21 01:57:56 UTC
Created attachment 124634 [details]
Konsole displaying incorrectly

Konsole claims this is point size 9 but it definitely is not when compared to my browser or LibreOffice.
Comment 3 Andrew Udvare 2019-12-21 02:17:12 UTC
Created attachment 124635 [details]
New user screenshot

This is from a new user account with minimal customisation, 1.5x scale enabled, 144 DPI force enabled (because that is what System Settings does automatically).

The left is Kate and the right KPatience. KPatience correctly shows its menus while Kate remains too large.
Comment 4 Andrew Udvare 2020-01-02 06:03:20 UTC
Created attachment 124839 [details]
VirtualBox screenshot

Found a non-KDE app affected: VirtualBox
Comment 5 Nate Graham 2020-01-02 17:16:32 UTC
Did you reboot after applying the 1.5x scale factor? Does the issue reproduce when switching to the Breeze widget style and Breeze icons and rebooting?
Comment 6 Andrew Udvare 2020-01-03 05:47:22 UTC
I rebooted and still get the same issue. About to try switching to Breeze widget style.
Comment 7 Andrew Udvare 2020-01-03 05:56:17 UTC
Rebooted with Breeze theme (and all other appearance settings set to Breeze) and still got the same issue.

Just for reference, this is a KF5 5.65.0 installation. Plasma-desktop and related is at 5.17.4. Qt is at 5.14.0.
Comment 8 Nate Graham 2020-01-03 16:48:48 UTC
Thanks.
Comment 9 Fabian Vogt 2020-01-07 08:44:00 UTC
Do the Qt applications look as expected if you force DPI to 96?

If so, it's probably Qt scaling fonts twice (1.5 * 144dpi = 216dpi) which amounts to a 2.25x scaling of fonts.
Comment 10 Luca Beltrame 2020-01-07 16:48:30 UTC
Yes, I confirm that setting DPI to 96 for fonts fixes the issue for me (although compared to the reporter, I have issues only in apps that use QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true)).
Comment 11 Nate Graham 2020-01-07 16:53:35 UTC
So maybe Qt 5.14 is double-scaling the fonts for apps using Qt::AA_EnableHighDpiScaling. :/ Sounds like maybe it's time for a Qt bug report. Any chance you could file one?
Comment 12 Andrew Udvare 2020-01-07 16:59:50 UTC
I currently have the broken apps forced to use 96 DPI but of course this means the toolbar icons, etc are very small on a 4K display.
Comment 13 David Edmundson 2020-01-07 17:12:30 UTC
It's probably accidentally fixed in Qt5.14.1 with c7fec68e1936576070d0fbac6cf40b818366d298 on QtBase, but that commit will break other things and I'm hoping it gets reverted.

There's some follow up on https://codereview.qt-project.org/c/qt/qtbase/+/285351
Comment 14 Nate Graham 2020-01-07 17:14:36 UTC
Either way, a Qt bug. Let's follow up upstream.

Thanks everyone!
Comment 15 Fabian Vogt 2020-01-08 20:15:43 UTC
The matching upstream bug report seems to be https://bugreports.qt.io/browse/QTBUG-80919

The "accidental fix" was part of the efforts for https://bugreports.qt.io/browse/QTBUG-80323
Comment 16 David Edmundson 2020-01-08 22:02:34 UTC
I think maybe this bug we're seeing is user's running plasma compiled against Qt5.13 on 5.14 - we introduced a change in startplasma, but we made that switch at compile time, which is arguably not right.
Comment 17 David Edmundson 2020-01-08 22:03:09 UTC
As you're on gentoo, can you be sure to re-emerge plasma-workspace after you upgraded Qt to rule that out?
Comment 18 Andrew Udvare 2020-01-09 02:27:57 UTC
(In reply to David Edmundson from comment #17)
> As you're on gentoo, can you be sure to re-emerge plasma-workspace after you
> upgraded Qt to rule that out?

Currently doing a system upgrade which update my system to 5.17.5. I will reboot after to make sure I'm running all newly built libs.
Comment 19 Andrew Udvare 2020-01-09 07:17:22 UTC
I updated and rebooted. This issue remains. I tested Ark, VirtualBox and Qt Designer. All 3 show large fonts.
Comment 20 Andrew Udvare 2020-01-09 07:19:10 UTC
Also one workaround for now that must be applied to the broken apps specifically is to use the QT_FONT_DPI environment variable. Setting this to 96 in the .desktop file for Kate/Dolphin/etc makes things seem normal again, and icons are the correct size.

 $ fgrep Exec ~/.local/share/applications/org.kde.kate.desktop
Exec=env QT_FONT_DPI=96 kate -b %U
Comment 21 Fabian Vogt 2020-01-10 08:40:00 UTC
(In reply to David Edmundson from comment #13)
> It's probably accidentally fixed in Qt5.14.1 with
> c7fec68e1936576070d0fbac6cf40b818366d298 on QtBase, but that commit will
> break other things and I'm hoping it gets reverted.

In a downstream bug report (https://bugzilla.opensuse.org/show_bug.cgi?id=1160624) I asked the reporter to test 5.14.0 with that commit applied and it's only a partial success:

> Thanks,the workarroun partial fix the issue but kwon decorations now are to
> small, I Will wait until the bug is solved.
Comment 22 Antonio Rojas 2020-01-11 18:04:01 UTC
*** Bug 416014 has been marked as a duplicate of this bug. ***
Comment 23 Antonio Rojas 2020-01-11 18:04:16 UTC
*** Bug 416124 has been marked as a duplicate of this bug. ***
Comment 24 postix 2020-01-16 18:40:37 UTC
(In reply to Nate Graham from comment #14)
> Either way, a Qt bug. Let's follow up upstream.
> 
> Thanks everyone!

Can you please point me to the Qt bug report? 

I first could workaround this by moving from the Manjaro testing branch to the stable branch, but with the latest update I'm not effected again and it's really annoying. :-(
Comment 25 Nate Graham 2020-01-16 19:26:09 UTC
I put it in the URL field of this bug report. :)
Comment 26 postix 2020-01-16 19:36:48 UTC
(In reply to Nate Graham from comment #25)
> I put it in the URL field of this bug report. :)

But it's not merged yet? Uh, this is really bothering me a lot. 
Any ETA?


(In reply to Andrew Udvare from comment #20)
> Also one workaround for now that must be applied to the broken apps
> specifically is to use the QT_FONT_DPI environment variable. Setting this to
> 96 in the .desktop file for Kate/Dolphin/etc makes things seem normal again,
> and icons are the correct size.
> 
>  $ fgrep Exec ~/.local/share/applications/org.kde.kate.desktop
> Exec=env QT_FONT_DPI=96 kate -b %U

Unfortunately this did only work for me for Kate and Okular. Konsole resists to
`env QT_FONT_DPI=96 konsole` in the desktop file.* I placed it at every Exec= line.
What I do now is, open Konsole and enter "env QT_FONT_DPI=96 konsole", which works...


* I made sure via updatedb && locate konsole.desktop that there's only one.
Comment 27 Fabian Vogt 2020-01-16 20:21:22 UTC
Even with the pending Qt patch for Xft.dpi merged, this doesn't seem to be completely fixed, see comment 21.

However, setting QT_AUTO_SCREEN_SCALE_FACTOR=0 seems to have universal success.

I tried to reproduce the issue in a VM and can't tell a difference between QT_AUTO_SCREEN_SCALE_FACTOR set to 0 and unset. So I assume this is related to the hardware's reported DPI. This makes sense considering that QT_AUTO_SCREEN_SCALE_FACTOR is about that - using hardware dpi / 96 for scaling.

So AFAICT QT_AUTO_SCREEN_SCALE_FACTOR=0 is still necessary even with Qt 5.14.x.

Reopening as this appears to require more discussion.

Note that the not directly related text rendering issue (https://bugreports.qt.io/browse/QTBUG-80967) should be fixed with Qt 5.14.1, but is also worked around by setting QT_AUTO_SCREEN_SCALE_FACTOR=0.
Comment 28 postix 2020-01-16 20:53:24 UTC
(In reply to Fabian Vogt from comment #27)
> However, setting QT_AUTO_SCREEN_SCALE_FACTOR=0 seems to have universal
> success.
> 


Thanks, I can confirm that! I had to revert the `Exec=env QT_FONT_DPI=96` changes in the desktop file and added `QT_AUTO_SCREEN_SCALE_FACTOR=0` to /etc/environment.
After rebooting everything went back to normal.

(Putting `export QT_AUTO_SCREEN_SCALE_FACTOR=0` into the .bashrc and logging out and back in again was not successfull for unknown reasons.)
Comment 29 Andrew Udvare 2020-01-16 21:16:39 UTC
The goal should be to have no extra environment variables set to solve this issue.
Comment 30 Andrew Udvare 2020-01-17 01:51:56 UTC
(In reply to Postix from comment #28)
> (In reply to Fabian Vogt from comment #27)
> > However, setting QT_AUTO_SCREEN_SCALE_FACTOR=0 seems to have universal
> > success.
> > 
> 
> 
> Thanks, I can confirm that! I had to revert the `Exec=env QT_FONT_DPI=96`
> changes in the desktop file and added `QT_AUTO_SCREEN_SCALE_FACTOR=0` to
> /etc/environment.
> After rebooting everything went back to normal.
> 
> (Putting `export QT_AUTO_SCREEN_SCALE_FACTOR=0` into the .bashrc and logging
> out and back in again was not successfull for unknown reasons.)

I put export QT_AUTO_SCREEN_SCALE_FACTOR=0 in my ~/.xprofile and everything works like it should.
Comment 31 Fabian Vogt 2020-01-21 10:56:50 UTC
Git commit ea66bff2af8466f2bb5acafcc43ac8f79b1f447f by Fabian Vogt.
Committed on 21/01/2020 at 10:56.
Pushed by fvogt into branch 'Plasma/5.18'.

Also disable automatic scaling on Qt >= 5.14

Summary:
Applications which set `Qt::AA_EnableHighDpiScaling` use the DPI of the monitor the window is on to calculate an additional scaling factor.
Plasma sets `QT_SCREEN_SCALE_FACTORS` in the environment for manual specification of per-monitor scale, which combined with the automatic scaling may result in double scaling.
To disable the automatic scaling, `QT_AUTO_SCREEN_SCALE_FACTOR=0` has to be set, even on Qt 5.14.

As a side effect, this works around QTBUG-80967 as well.

Test Plan: On X11, with a >144dpi monitor and a scaling factor of 2 set manually, scaling was doubled previously. Now it works as expected.

Reviewers: #plasma, apol, davidedmundson, fvogt

Reviewed By: #plasma, davidedmundson, fvogt

Subscribers: acooligan, fvogt, asturmlechner, dfaure, davidedmundson, anthonyfieroni, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D26185

M  +0    -2    startkde/startplasma.cpp

https://commits.kde.org/plasma-workspace/ea66bff2af8466f2bb5acafcc43ac8f79b1f447f
Comment 32 Andrew Udvare 2020-04-18 08:02:58 UTC
(In reply to Fabian Vogt from comment #31)
> Git commit ea66bff2af8466f2bb5acafcc43ac8f79b1f447f by Fabian Vogt.
> Committed on 21/01/2020 at 10:56.
> Pushed by fvogt into branch 'Plasma/5.18'.
> 
> Also disable automatic scaling on Qt >= 5.14
> 
> Summary:
> Applications which set `Qt::AA_EnableHighDpiScaling` use the DPI of the
> monitor the window is on to calculate an additional scaling factor.
> Plasma sets `QT_SCREEN_SCALE_FACTORS` in the environment for manual
> specification of per-monitor scale, which combined with the automatic
> scaling may result in double scaling.
> To disable the automatic scaling, `QT_AUTO_SCREEN_SCALE_FACTOR=0` has to be
> set, even on Qt 5.14.
> 
> As a side effect, this works around QTBUG-80967 as well.
> 
> Test Plan: On X11, with a >144dpi monitor and a scaling factor of 2 set
> manually, scaling was doubled previously. Now it works as expected.
> 
> Reviewers: #plasma, apol, davidedmundson, fvogt
> 
> Reviewed By: #plasma, davidedmundson, fvogt
> 
> Subscribers: acooligan, fvogt, asturmlechner, dfaure, davidedmundson,
> anthonyfieroni, plasma-devel
> 
> Tags: #plasma
> 
> Differential Revision: https://phabricator.kde.org/D26185
> 
> M  +0    -2    startkde/startplasma.cpp
> 
> https://commits.kde.org/plasma-workspace/
> ea66bff2af8466f2bb5acafcc43ac8f79b1f447f

That fix resolves most of the issue but Chrome seems to now run with a reduced environment. /proc/<chrome PID>/environ shows a very minimal environment. As a result, when Chrome launches Ark (click on item in the download bar) I get the same issue. I modified the .desktop file to force the QT_AUTO_SCREEN_SCALE_FACTOR=0 value and it works. I wouldn't want to have to create custom .desktop files just for Chrome. Should I file another ticket?
Comment 33 Fabian Vogt 2020-04-18 09:25:34 UTC
(In reply to Andrew Udvare from comment #32)
> That fix resolves most of the issue but Chrome seems to now run with a
> reduced environment. /proc/<chrome PID>/environ shows a very minimal
> environment. As a result, when Chrome launches Ark (click on item in the
> download bar) I get the same issue. I modified the .desktop file to force
> the QT_AUTO_SCREEN_SCALE_FACTOR=0 value and it works. I wouldn't want to
> have to create custom .desktop files just for Chrome. Should I file another
> ticket?

Yes, that seems unrelated.