diff options
author | Tor Arne Vestbø <tor.arne.vestbo@qt.io> | 2019-11-28 17:46:34 +0100 |
---|---|---|
committer | Tor Arne Vestbø <tor.arne.vestbo@qt.io> | 2019-11-29 12:37:44 +0100 |
commit | 6ec5a97ebbf65a9283a57b8e5f4192e7ec84a759 (patch) | |
tree | ffcaf4e9aeaa18ae6429d67c32f6b548eba0285f /mkspecs/features/android/android.prf | |
parent | 0b2f13924263ad37e1654a856deb26601d09c4b4 (diff) |
macOS: Harden screen handling logic when reconfiguring displays
When connecting/disconnecting/reconfiguring screens Qt needs to know
about the changes before they are propagated by the OS in other ways,
so that we can reflect the changes in the list of QScreens as soon as
they happen.
Unfortunately the canonical notifications for this in AppKit,
NSApplicationDidChangeScreenParametersNotification, is delivered
after AppKit itself reacts to the change, which results in receiving
NSWindowDidChangeScreenNotification, NSWindowWillMoveNotification,
and others, while the list of QScreens is stale.
To work around this we adopted the lower layer Quartz Display
Services API in 3976df2805 to notify us when there are changes to
the screen configuration.
Unfortunately the window server on macOS is not consistent in how
it orders events during screen reconfiguration, and we can't rely
on the NSScreen list being up to date when we get our callbacks
from Quartz.
To work around this we still hook into Quartz, so that we get the
callbacks as early as possible, but then track the state of the
AppKit NSScreen list and update our own QScreens as soon as we
see a change.
We now also include sleeping displays in the list of QScreens,
which matches the behavior of NSScreen.screens. Similarly we
exclude displays that are mirroring another display.
Task-number: QTBUG-80193
Change-Id: I6b1958d6ee61373b2861e05a0d971d2300596f3e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Diffstat (limited to 'mkspecs/features/android/android.prf')
0 files changed, 0 insertions, 0 deletions