...and the view is using a CAMetalLayer and a non-default contents
placement. (the default would be scaling/stretching of the content,
that hides a lot of out-of-sync size problems during resize, but
is not great for UIs so we never use that in practice)
This achieves two things:
- when presenting from the main thread with transactions (i.e. with
parent patch in place), resizing the window will be even nicer,
basically flicker free on the M1 Mini as well,
- when presenting from outside the main thread, resizing becomes
a lot smoother, even if the window background is still visible
from time to time due to the size not catching up and due to
Qt having to use NSViewLayerContentsPlacementTopLeft.
Thus resizing Qt Quick-based windows, which use the threaded render
loop by default and cannot use presentsWithTransaction, becomes a
nicer experience than before, even if not always perfect.
This comes at the expense of not animating during the live resize
operation whenever the size is not changed (because only a resize
triggers updates then, the CVDisplayLink-based updates are skipped
in order to reduce flicker due to out of sync sizes)
To force the old behavior, set QT_MAC_DISPLAY_LINK_UPDATE_IN_RESIZE.
Task-number: QTBUG-107198
Change-Id: I796c3a74119510c62f7245b0ebbe78797d2df03e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
fa3bfa72da