Details
-
Bug
-
Resolution: Fixed
-
P1: Critical
-
6.3.0, 6.4
-
Windows 10 Pro 21H2
Description
It looks like on Windows, the Qt neither reacts to nor provides any notifications to DPI changes, if the Qt window is not a top-level window but is embedded into a non-Qt parent.
We have provided a minimum test example (see attached file). It is to be run from under a debugger on Windows with a breakpoint set inside the lambda at line 77. First, left-click on the red vector image inside the test app window. It will dump the current devicePixelRatio into the debug console (the dumping code is in line 39). Now change the system DPI setting in the Windows Settings to a different value (e.g. from 100% to 125%). Left-click the red vector image again to get the new devicePixelRatio dumped into console.
Expected results:
- the DPI change notification breakpoint in line 77 is triggered
- the new DPI value in the console is correct
- the physical size of the red vector image is rescaled proportionally to the DPI change
Observed results:
- the breakpoint is not triggered
- the new DPI value is the same as the old one
- the physical size of the red vector image is unchanged
NB1. Depending on your Windows system configuration, changing the system DPI settings might require re-logging-in and refuse to work on-the-fly while the app is running. This seems to be the case if you have enabled the custom DPI scaling option on your system, so you might want to turn that one off.
NB2. To confirm that this is related to the non-Qt parent window, you may comment out the setParent() call in line 73. In this case the test example works as expected in all the 3 aspects listed above.
You can also run the two versions of this demo app (with setParent() and with commented out setParent()) side-by-side. When changing the system DPI ratio setting you can observe the Qt image changing its size in the app without setParent() call, as expected, while the one with the setParent() call doesn't change its size (as it doesn't respond to the DPI change).
NB3. The primary actual use case is dragging the window from a monitor with one DPI ratio to another monitor with a different DPI ratio. But, as we found out, from the app's perspective it seems to be equivalent, and changing the system settings is easier to work with (esp. if you don't have a second monitor) and to interpret the visual results.
Attachments
Issue Links
- is cloned by
-
QTBUG-103806 Windows: Qt doesn't respond to DPI changes if Qt window is having a non-Qt parent (cloned)
- Closed
- relates to
-
QTBUG-102343 Windows: Only initial QScreen values are available if screen geometry changes between QApplication and before first window is open
- Closed
For Gerrit Dashboard: QTBUG-103383 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
415957,4 | Windows QPA: Update screen on child window DPI change | dev | qt/qtbase | Status: MERGED | +2 | 0 |
416747,4 | Windows: Decouple screen change monitoring from top level QWindows | dev | qt/qtbase | Status: MERGED | +2 | 0 |
416803,4 | Windows: Don't rely on top level QWindow to scale children on DPI change | dev | qt/qtbase | Status: MERGED | +2 | 0 |
416883,2 | Windows QPA: Update screen on child window DPI change | 6.4 | qt/qtbase | Status: MERGED | +2 | 0 |
417128,2 | Windows: Decouple screen change monitoring from top level QWindows | 6.4 | qt/qtbase | Status: MERGED | +2 | 0 |
417940,4 | Windows QPA: Update screen on child window DPI change | 6.3 | qt/qtbase | Status: MERGED | +2 | 0 |
417941,4 | Windows: Decouple screen change monitoring from top level QWindows | 6.3 | qt/qtbase | Status: MERGED | +2 | 0 |
419523,2 | Windows: Don't rely on top level QWindow to scale children on DPI change | 6.4 | qt/qtbase | Status: MERGED | +2 | 0 |