[hidpi] linux GUI does not scale properly

[zorael]

Running Manjaro/Arch, Qt packages are version 5.9.1-3, KWin/Plasma 5.10.4. rpcs3 tested as both AppImage (b01e7e3) and compiled from the AUR (e9b020bea).

On a hidpi display the linux graphical interface has weird icon sizes and weird paddings. On this particular Dell XPS 13 machine, running with a 3200x1800 resolution scaled up 1.5x using KDE's built-in scaling, the CPU Configuration window is too tall to fit the Save/Close buttons on the screen. The AppImage fares slightly better than the AUR-compiled build, but neither look good.

Example of the AppImage: https://i.imgur.com/Wzt8KBO.png Example of the self-compiled build: https://i.imgur.com/EUKI725.png Example of the too-large CPU settings window: https://i.imgur.com/4tGOVB1.png

Unsetting the QT_SCREEN_SCALE_FACTOR environment variable makes the AppImage display properly, The compiled one still has bad padding.

$ QT_SCREEN_SCALE_FACTOR= ./rpcs-*.AppImage

Example of AppImage without QT_SCREEN_SCALE_FACTOR: https://i.imgur.com/w5SHGCn.png Example of self-compiled, likewise: https://i.imgur.com/D4emhGD.png

[Megamouse]

Nothing I can do

https://bugreports.qt.io/browse/QTBUG-57211

[Megamouse]

can you try this with the latest master build again? just to make sure it's still happening

[zorael]

I tried compiling rpcs3-git from AUR but it doesn't build, apparently due to missing LLVM 4 packages. Qt5 packages are version 5.9.2-1, kwin 5.11.2-1.

The AppImage works and its scaling is still off: https://i.imgur.com/SQ2rMS4.png

My QT_SCREEN_SCALE_FACTOR is empty nowadays; unsure where this is set, or maybe Qt doesn't rely upon it anymore? As such I can't unset it and force scaling as I could before. The CPU configuration window still doesn't fit this 3200x1800 display.

[zorael]

I misspelled the variable, it's supposed to be plural FACTORS.

With it unset it's better but still a bit awkward, as before: https://i.imgur.com/DvmIVk7.png

[Megamouse]

else

qputenv("QT_AUTO_SCREEN_SCALE_FACTOR", "1");

endif

this is what we do

[zorael]

I'll see if I can manage to get rpcs3-git to build and comment out that line. It looks like it involves compiling all of LLVM 4 on this laptop though.

[zorael]

It looks much, much better now that I can unset QT_AUTO_SCREEN_SCALE_FACTOR. It scales as it should.

https://i.imgur.com/NIUWADW.png

Maybe we can leave QT_AUTO_SCREEN_SCALE_FACTOR unset if the explicit QT_SCREEN_SCALE_FACTORS is set?

[AniLeo]

Can you retest on latest build?

[zorael]

Still big when compiled via aur/rpcs3-git, https://i.imgur.com/5KxsLV7.png. No environment variables were unset.

[hcorion]

Can you re-test on latest build? Both AppImage and the AUR package.

[zorael]

aur/rpcs3-git: https://i.imgur.com/5PnGC5c.png AppImage 6498-7233640c: https://i.imgur.com/lObhXi8.png

rpcs3-git is enormous, while the AppImage interface size is usable but not good.

Overall QT_AUTO_SCREEN_SCALE_FACTOR=1 wrecks the sizes of any and all programs I open. e.g. kate becomes unusable: https://i.imgur.com/eSbZ6Yb.png. Being able to unset it fixes things, which I can't with that hardcoded qputenv.

In what kind of setups does it actually help?

[Megamouse]

did you create an issue on qt bug tracker?

[Megamouse]

if (qgetenv("QT_AUTO_SCREEN_SCALE_FACTOR").isEmpty()) qputenv("QT_AUTO_SCREEN_SCALE_FACTOR", "1"); maybe try something like that?

[Megamouse]

summons @hcorion do you know if this is still useful?

[hcorion]

I'm not sure, I don't have any hidpi screens to test @zorael is this still an issue?

[C0sm1x]

Chaning

qputenv("QT_AUTO_SCREEN_SCALE_FACTOR", "1");

to

qputenv("QT_AUTO_SCREEN_SCALE_FACTOR", "0");

Fixed the scaling issue for me. Why doesn't rpcs3 use the system's QT_AUTO_SCREEN_SCALE_FACTOR environment variable? I had to change the code and compile.

[Vosester]

RPCS3 still does not honour QT_AUTO_SCREEN_SCALE_FACTOR, whoever hard-coded this environment variable, needs to pay all the money I lost to the swear jar.

[Johndeep]

After posting in the wrong category before, I think this place should be the correct one to address the qt gui interface issue I have, especially since it is about scaling, coming from Linux Debian Testing.

I normally have a FullHD screen (1080p) but even if I have the Default Resolution "1280x720 (Recommended)" option enabled, the window always scales double the configured size. Furthermore, every buttons and other elements are far too big, but the font are too small in comparison.

I misspelled the variable, it's supposed to be plural FACTORS.

With it unset it's better but still a bit awkward, as before: https://i.imgur.com/DvmIVk7.png

I always thought that the scaling like above is the norm, until I found out that it is not! Even with export QT_AUTO_SCREEN_SCALE_FACTOR=0, there is no change at all. Maybe a proper upgrade to qt 5.11 might solve the issue altogether? But In other issues, I saw that it has compiling issues, so yeah.

[Johndeep]

@C0sm1x would you be kind and make a PR of the change to qputenv("QT_AUTO_SCREEN_SCALE_FACTOR", "0");? I at least want to try a compiled version to check if it works if it is okay. I would want to try, if scaling with qt5ct or environment variables is possible with such a PR.

[ghost]

For the record, I'm running RPCS3 on Ubuntu 19.04 with 2x scaling and everything is as it should be.

Fractional scaling might be part of the issue.

[Johndeep]

Just for confirmation, @drysalter, does the GUI looks like this (or similar)? Because this is where the icons are far too big, while the font is staying in the same size.

But well, it might be that I use XFCE (but why, because of different gui render engine)? But again, qt5.x prior to 5.10 (e.g. 5.6) and after 5.10 (e.g. 5.11) are totally okay and with correct scaling (can only confirm in other apps with qt running. They might know this and almost everyone avoid version 5.10, by staying at a lower version or skip 5.10 altogether it seems).

[Johndeep]

Well okay, I actually did the hassle to compile everything myself to see, if this is really due to qt5. By the way, my system is Debian based on the Unstable channel.

To my surprise, the GUI finally looks.. correct! The "About Qt" says it's version 5.11.3. Some short test were made like starting games to see, if there are qt specific issues, but for now, there are none.

Furthermore, qt5ct would be now working properly to translate the gui into a nice gtk+ look.

Maybe it is time to update the qt version in the online builder to at least 5.11.3 (would like to do it, but don't know where). This might cause other regressions, so you might want to test it yourself first. It also might solve #5820.

[Megamouse]

we're looking into it. seems linux appimages might indeed be running on 5.10.1 right now. I think I pushed it to 5.11 at one point but we changed the build process and it had to be downgraded again for a lack of available sources.

[ghost]

Here's the toolbar (AppImage, Qt 5.10.1) on Ubuntu 19.04 in case you're still wondering:

Worked just as well on 18.10.

Here it is compiled from source (Qt 5.12.2):

Everything is a bit bigger, but proportional nonetheless.

[Megamouse]

Apart from the highdpi changes in Qt this may also partly be caused by a minimal change in style between 5.10 and 5.11 that I had to try to fix by using slightly different code for versions below 5.11. But those fixes are purely style and do not change anything regarding the actual scaling and the change (if it is what we are seeing) should only appear on the default style.

[Johndeep]

@drysalter yes, that's very intriguing, does this depend on the window drawing engine I wonder? But that's stupid. QT should not depend on any underlying desktops or render engines. Well, either way, I'm okay with something at least away from 5.10. Hopefully an AppImage with qt 5.11+ won't inherit this scaling issue. (I know, very unlikely, but still, who knows).

[Enverex]

So it turns out that qputenv("QT_AUTO_SCREEN_SCALE_FACTOR", "1"); is what's breaking RPCS3 for me as well (opens 16kx16k window, without it it works fine). Is there any way of stopping it from doing this other than modifying the source and recompiling?

EDIT: After rebuilding with that line removed from the source, it works fine, so that definitely is the cause.

[Megamouse]

Qt was updated and a few cli arguments were added on our side to manually override these things. Closing in hopes that this can be fixed on user side now. Please open a new issue if you can't get it to work.