Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. QML and Qt Quick
  4. qmlRegisterType and the UI thread
Forum Updated to NodeBB v4.3 + New Features

qmlRegisterType and the UI thread

Scheduled Pinned Locked Moved Solved QML and Qt Quick
4 Posts 3 Posters 621 Views 2 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • VStevenPV Offline
    VStevenPV Offline
    VStevenP
    wrote on last edited by
    #1

    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?

    jeremy_kJ eyllanescE 2 Replies Last reply
    0
    • VStevenPV VStevenP

      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?

      jeremy_kJ Offline
      jeremy_kJ Offline
      jeremy_k
      wrote on last edited by
      #2

      @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.

      Asking a question about code? http://eel.is/iso-c++/testcase/

      1 Reply Last reply
      1
      • VStevenPV VStevenP

        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?

        eyllanescE Offline
        eyllanescE Offline
        eyllanesc
        wrote on last edited by eyllanesc
        #3

        @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.

        If you want me to help you develop some work then you can write to my email: e.yllanescucho@gmal.com.

        1 Reply Last reply
        0
        • VStevenPV Offline
          VStevenPV Offline
          VStevenP
          wrote on last edited by
          #4

          Thank you all for your comments; they are extremely useful.

          1 Reply Last reply
          0

          • Login

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • Users
          • Groups
          • Search
          • Get Qt Extensions
          • Unsolved