whytofly
/
qt6-bb10
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

macOS: Don't rely on QGuiApplication::instance() during CVDisplayLink callback 

The display-link callback comes in on a secondary thread, so there's a possible
race in using QGuiApplication::instance() to check whether or not we're on the
main thread.

Change-Id: Ic26bca8f5f54847a1e1b11dc92e786693c86e9de
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
bb10
Tor Arne Vestbø 2019-02-07 17:27:18 +01:00
parent ae94ab264b
commit 0ad651579f
1 changed files with 1 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
src/plugins/platforms/cocoa/qcocoascreen.mm
View File

@ -269,15 +269,12 @@ struct DeferredDebugHelper
void QCocoaScreen::deliverUpdateRequests()
{
if (!QGuiApplication::instance())
return;
// The CVDisplayLink callback is a notification that it's a good time to produce a new frame.
// Since the callback is delivered on a separate thread we have to marshal it over to the
// main thread, as Qt requires update requests to be delivered there. This needs to happen
// asynchronously, as otherwise we may end up deadlocking if the main thread calls back
// into any of the CVDisplayLink APIs.
if (QThread::currentThread() != QGuiApplication::instance()->thread()) {
if (!NSThread.isMainThread) {
// We're explicitly not using the data of the GCD source to track the pending updates,
// as the data isn't reset to 0 until after the event handler, and also doesn't update
// during the event handler, both of which we need to track late frames.