[Windows] High DPI Displays and scale factor != 100%
- Dominant language
- C++
- Stars
- 552
- Forks
- 284
- Avg merge
- 9d 6h
- Merged PRs (30d)
- 5
Description
In the last releases Qt has been introducing support for high DPI Displays (https://doc.qt.io/qt-5/highdpi.html). According to the documentation, High DPI support is enabled from Qt 5.6 onward
In a Windows PC, in high DPI displays when using scaling, DLT-viewer looks weird. The Qt Widgets seem to be scaled twice: once by the system, and another by Qt.
The screenshot below compares DLT-Viewer 2.16 (Qt 5.5) with DLT-Viewer 2.21 (Qt 5.14) and windows explorer in a high DPI display (4k resolution, 27") with 150% scaling (no photoshop: the three windows are rendered in the same screen at the same time).
Compare the text size (menus) and toolbar icons in the three windows. Note also some rendering artifacts in old DLT-Viewer

The problems become worse in combination with multiple displays and different scale factors.
This might seem a Qt issue, and not related to DLT-Viewer. However, making the application High DPI and scaling aware could improve rendering (similar experience to Ms. Windows) in all kind of combinations (multiple monitors and different scale factors).
According to the Qt documentation about HighDpiScaleFactorRoundingPolicy (https://doc.qt.io/qt-5/qt.html#HighDpiScaleFactorRoundingPolicy-enum) and the results observed rounding seems to apply for non integer scaling factors (like 150%) making Qt to scale (again) the widgets. Setting the environment variable `QT_SCALE_FACTOR_ROUNDING_POLICY` to "Passthrough" before starting Dlt-Viewer makes the DLT-Viewer to look nice again in all monitors (also with different scaling).
Comparison of Dlt-Viewer in a high DPI display (4k resolution, 27") with 150% scaling and Passthrough rendering policy.

It seems that MS Windows provides an API (*SetProcessDPIAware()*) which shall/could be used in this cases...
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setprocessdpiaware
In the following links several solutions are presented, using the previous MS Windows APIs:
* https://vicrucann.github.io/tutorials/osg-qt-high-dpi/
* https://forum.freecadweb.org/viewtopic.php?t=52307
* https://www.programmersought.com/article/89186999411/
**Additional web resources**:
* https://www.enpass.io/support/kb/troubleshooting/enpass-looks-too-small-or-big-on-my-display-how-can-i-fix-it/
* https://wiki.qt.io/New_Features_in_Qt_5.14
* https://unix.stackexchange.com/questions/433385/scaling-hidpi-issue-for-qt5-applications-under-gnome
* https://stackoverflow.com/questions/36134072/setprocessdpiaware-seems-not-to-work-under-windows-10
* https://stackoverflow.com/questions/22674331/how-to-avoid-dpi-awareness-in-a-qtapplication-for-windows
* https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setprocessdpiaware
Contributor guide
No contributing guide indexed for this repository
Research direction
Reproduce DLT-Viewer on Windows with a 4K display at 150% scaling, including multiple monitors with different scale factors. Start by reviewing the Qt high-DPI documentation and the Windows SetProcessDPIAware API, then compare behavior with QT_SCALE_FACTOR_ROUNDING_POLICY set to "Passthrough". Done means widgets and toolbar icons render correctly without double scaling or artifacts.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- desktop, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100