qmlRegisterType and the UI thread
-
If you expose a class to QML via qmlRegisterType(), then use that class in QML, is that object an object of the UI thread or a different thread?
I'm trying to make sure I keep backend processing out of the UI thread, since it can be time-consuming, and I don't wish to slow down the UI frame update rate.
In a similar way, does instantiating the same object in main.cpp using C++, then exposing that object to QML via setContextProperty() ensure that the object is not an object of the UI thread, and therefore will not potentially slow down the UI frame update rate?
Is there a good, clear discussion of this anywhere in the documentation?
-
If you expose a class to QML via qmlRegisterType(), then use that class in QML, is that object an object of the UI thread or a different thread?
I'm trying to make sure I keep backend processing out of the UI thread, since it can be time-consuming, and I don't wish to slow down the UI frame update rate.
In a similar way, does instantiating the same object in main.cpp using C++, then exposing that object to QML via setContextProperty() ensure that the object is not an object of the UI thread, and therefore will not potentially slow down the UI frame update rate?
Is there a good, clear discussion of this anywhere in the documentation?
@VStevenP said in qmlRegisterType and the UI thread:
If you expose a class to QML via qmlRegisterType(), then use that class in QML, is that object an object of the UI thread or a different thread?
The created object's thread affinity is the same as the engine that created it. I don't know if it's possible to create a QQmlEngine in a non-UI thread. It might work if Quick isn't involved.
I'm trying to make sure I keep backend processing out of the UI thread, since it can be time-consuming, and I don't wish to slow down the UI frame update rate.
In a similar way, does instantiating the same object in main.cpp [...]
main.cpp, or any C++ file doesn't relate to thread affinity. The same code can be called from multiple threads, including ::main(). The affinity is initially assigned to the thread that instantiates the QObject, or the object's parent. It's common but not required to instantiate the QGuiApplication from the initial thread, making the first thread that entered main() the UI thread.
[...], then exposing that object to QML via setContextProperty() ensure that the object is not an object of the UI thread, and therefore will not potentially slow down the UI frame update rate?
Setting the object as a context property means that access to that property will be run in the thread the QML engine is associated with, usually the UI thread per discussion above. If you need to move computation out of the UI thread, do it with signals and slots or another IPC mechanism. Use an object exposed to the engine as a proxy.
Is there a good, clear discussion of this anywhere in the documentation?
Other than the general documentation of QObject thread affinity for parentless and parented objects, I don't know of anything.
-
If you expose a class to QML via qmlRegisterType(), then use that class in QML, is that object an object of the UI thread or a different thread?
I'm trying to make sure I keep backend processing out of the UI thread, since it can be time-consuming, and I don't wish to slow down the UI frame update rate.
In a similar way, does instantiating the same object in main.cpp using C++, then exposing that object to QML via setContextProperty() ensure that the object is not an object of the UI thread, and therefore will not potentially slow down the UI frame update rate?
Is there a good, clear discussion of this anywhere in the documentation?
@VStevenP QObjects created in QML are created in the main thread.
Note: QML connections are made using Qt::DirectConnection so the sender/receiver must live in the main thread so if you want to launch any task in a secondary thread from QML then you must use workerscript or use a QObject as proxy to launch the task in another thread and forward the information to QML.
