The WM_DISPLAYCHANGE message it sent when displays are added, removed,
or update their properties such as the scale/DPI.
We were processing this message as part of QWindowsContext::windowsProc(),
which meant that we would only react to display changes if there was a
QWindow on screen. Just creating a QGuiApplication was insufficient to
pick up changes to screens after startup.
In addition, despite being documented to post messages to child windows,
WM_DISPLAYCHANGE only ends up in top level windows. Presumably it's the
top level window's responsibility to post the message to child windows.
As a result, if a QWindow was a native child window of a foreign window,
such as in audio plugins being hosted in a DAW, we would again fail to
pick up display changes.
We solve both these cases by decoupling the WM_DISPLAYCHANGE handling
from QWindowsContext::windowsProc(), by creating a dedicated window
for listening to WM_DISPLAYCHANGE. This is similar to how we already
handle tray icons, power notifications, clipboard, etc -- the only
difference being that since purely HWND_MESSAGE windows do not
receive WM_DISPLAYCHANGE it's an actual invisible WS_TILED window.
This also lets us remove the workaround for QTBUG-79248, which was
doing screen updates in response to WM_DPICHANGED when detecting
that there were no QWindows.
Task-number: QTBUG-103383
Task-number: QTBUG-79248
Fixes: QTBUG-102343
Pick-to: 6.4
Change-Id: I905d8253069ec339b193edf05c052d21361ca3e9
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
fa0b2ef81c