Client/Console is overscaled on high DPI

[CaptainFlint]

Windows 10, DPI is set to 150%. When I start Aspia client or console (have not checked other components), the UI is scaled too much, looks like 200% or so.

Here are some screenshots.

1. How Console looks with normal 100% scaling.
2. The previous image streched to 150% in an image editor, as an illustration of what I would expect to see.
3. What Console actually looks like when Windows DPI is set to 150%.

You can see that the window titlebar is approximately the same in the 3rd and the 2nd images. It means, that OS shows the system window areas scaled to 150%, just as expected. However, the internal client area elements (fonts, icons, etc.) are way too big in the 3rd image.

I have not looked at the code, but is it possible that, for example, Qt already takes care of all the scaling, and you then add your own scaling on top of that?

OS: Windows 10 x64 1909 Aspia 2.4.0.

[dchapyshev]

All scaling is handled by Qt. Aspia does not control it.

[CaptainFlint]

I have other Qt applications, and they don't do such an over-scaling, but show elements with normal 150% size, as expected.

[CaptainFlint]

I googled a bit, and it seems the issue with Qt scaling by 200% when Windows is set at 150% is a known behavior, it just rounds it to the nearest integer which is 2 (200%). To avoid this, it's recommended to use QGuiApplication::highDpiScaleFactorRoundingPolicy with policy set to PassThrough.

I tried overriding the policy using environment variable QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough, and, indeed, the scale became consistent with the OS.

Although there is another issue which, I guess, has to be treated with custom code. When I connect to remote host, and choose Automatic window size, it's calculated pre-scaled (that is, 200% of the real host screen size when started normally, or 150% size when run with QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough). My guess is, screen size is probably calculated using the same virtual pixel units as the rest of the UI, and therefore has the same scale. But in this case pixels should be mapped directly into pixels, without scaling.

[dchapyshev]

Thanks for your research into the problem. I will try to take this into account in the next release.

[dchapyshev]

Fixed in 2.5.0 version.

[940842546]

Fixed in 2.5.0 version. no, it's already exists As a comparison,set system environment variables Qt_ENABLE_HIGHDPI_SCALING=0 and QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough,it's not overscaled

[dchapyshev]

In the original problem, it was described that the application looks larger than other applications on the system. This issue has been fixed and now the app size looks the same as other apps. When you set the Qt_ENABLE_HIGHDPI_SCALING parameter to 0, the application completely stops adjusting to the DPI in the system. This is incorrect behavior. The application must be able to scale according to the DPI. Moreover, in Qt 6, the Qt_ENABLE_HIGHDPI_SCALING parameter is declared obsolete and scaling is always enabled. High DPI scaling disabled: High DPI scaling enabled:

[940842546]

In the original problem, it was described that the application looks larger than other applications on the system. This issue has been fixed and now the app size looks the same as other apps. When you set the Qt_ENABLE_HIGHDPI_SCALING parameter to 0, the application completely stops adjusting to the DPI in the system. This is incorrect behavior. The application must be able to scale according to the DPI. Moreover, in Qt 6, the Qt_ENABLE_HIGHDPI_SCALING parameter is declared obsolete and scaling is always enabled. High DPI scaling disabled: High DPI scaling enabled:

nono i mean the display the display is overscale this is the compare with teamviewer