5.12.10, 5.14.2, 5.15.2
Any windows system with multiple monitors attached, and having different scale factors set (e.g. 100% and 150%).
6336b5350b68e6430a7585d6658a9d653689186f (qt/qtbase/dev) da68ad52104c67a39c8d8c8203ef6969b0a474f1 (qt/qtbase/6.2)
This bug is very closely related to
If winId() is called in any widget managed by QScrollArea, the widget will fail to re-layout correctly when moved between mixed scale factor monitors on Windows. The result is a garbled mess of what looks like the layouts from both scale factors, and is unusable. This only happens if the Qt property AA_EnableHighDPIScaling is set on the application.
Our applications need to be able to use winId() within widget hierarchies to accomplish tasks such as hooking into native events, and doing direct screen rendering on native windows.
A fix was put in place for
QTBUG-82312 that corrected those specific behaviors outlined in that defect, but appear to have now introduced these layout issues. This behavior does not exist in Qt 5.9.9 or earlier.
I've attached a modified version of the program I provided in
QTBUG-82312 that illustrates this behavior. It simply draws a number of buttons on a widget, and shows how those get mangled when the widget is moved to a different scale factor monitor.
The call to winId() is on line 25 of MainView.cpp. If this is commented out, the layout works correctly once more.
|For Gerrit Dashboard: QTBUG-89294|
|327856,8||Windows: scale child platform windows on DPI change||dev||qt/qtbase||Status: ABANDONED||0||0|
|356771,6||Improve WM_DPICHANGED handling||dev||qt/qtbase||Status: MERGED||+2||0|
|363504,2||Improve WM_DPICHANGED handling||6.2||qt/qtbase||Status: MERGED||+2||0|