Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. Game Development
  4. Threads - stop/ resume
Forum Updated to NodeBB v4.3 + New Features

Threads - stop/ resume

Scheduled Pinned Locked Moved Game Development
6 Posts 4 Posters 5.7k Views 1 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.
  • C Offline
    C Offline
    ChevLucas
    wrote on last edited by
    #1

    Hi, I created a class and add it to a new thread (this-> moveToThread (QThread *));
    everything works nicely, I connected the signals of this class of functions that run in the main thread. I had to do that because the threads controls the labels that appear on the form. But I need also draw lots of labelów position. Initially, the draw takes place in the constructor, so before class will run in a separate thread. However, when the draw takes place when a thread already going on, something is not working properly. It seems to me that if they stop the thread and draw function to perform in the main thread if it would work around, however, I do not know how to stop the thread, thrown out of the class to perform the function and back to give this-> moveToThread (QThread *), thread-> start ();

    I use the label as a vehicles to simulate the intersection based on the right-hand rule. When the car reaches the end, the draw for starting positions and to take place again. Depending on the starting position rotates the image in the page, unfortunately the new draw, the images are not displayed correctly.

    1 Reply Last reply
    0
    • JKSHJ Offline
      JKSHJ Offline
      JKSH
      Moderators
      wrote on last edited by
      #2

      Hi,

      How do you control the drawing? Paint events can only be handled in the main thread -- you can't draw anything from a secondary thread. You can use your new thread to calculate the POSITIONS of the car, but you need to send the position data back to the main thread for drawing.

      By the way, have a look at the "Graphics View Framework":http://qt-project.org/doc/qt-4.8/graphicsview.html -- it might suit your use case better than QLabels

      Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

      1 Reply Last reply
      0
      • JKSHJ Offline
        JKSHJ Offline
        JKSH
        Moderators
        wrote on last edited by
        #3

        As for actually pausing/resuming threads, that can only be done via "QtConcurrent":http://qt-project.org/doc/qt-4.8/qtconcurrent.html . However, the implementation isn't very good, and the Qt developers are thinking of replacing it.

        Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

        1 Reply Last reply
        0
        • K Offline
          K Offline
          KA51O
          wrote on last edited by
          #4

          [quote author="JKSH" date="1358642073"]As for actually pausing/resuming threads, that can only be done via "QtConcurrent":http://qt-project.org/doc/qt-4.8/qtconcurrent.html . However, the implementation isn't very good, and the Qt developers are thinking of replacing it.[/quote]

          Well actually he wouldn't need to pause the thread, he just needs to pause his worker object he moved to the thread. This can either be done by disconnecting the worker from all the relevant signals he receives, or by having another connection (e.g.: @ connect(objectInMainThread, SIGNAL(pauseWorkerRequested()), workerObjectInOtherThread, SLOT(pauseWorker()));@ ) that could set a flag in the worker object causing him to pause.

          1 Reply Last reply
          0
          • F Offline
            F Offline
            feldifux
            wrote on last edited by
            #5

            There was a blog post today from the Woboq team about correct thread usage:

            http://woboq.com/blog/qthread-you-were-not-doing-so-wrong.html

            This was the reference document for thread implementations done right earlier (which Olivier also is referencing in his blog post): http://blog.qt.digia.com/blog/2010/06/17/youre-doing-it-wrong/

            Cheers,
            Chris

            Founder of Felgo SDK - http://felgo.com/qt

            Felgo simplifies

            • Mobile App Dev with Qt esp. iOS & Android
            • Game Development with Qt

            What others say

            Felgo scored #1 in Cross-Platform App Development Tools Report - see why: https://goo.gl/rgp3rq

            1 Reply Last reply
            0
            • K Offline
              K Offline
              KA51O
              wrote on last edited by
              #6

              [quote author="feldifux" date="1358884071"]There was a blog post today from the Woboq team about correct thread usage:
              http://woboq.com/blog/qthread-you-were-not-doing-so-wrong.html
              [/quote]

              I don't agree with the argumentation the author of the article mentioned by you above uses. Especially the example which is given. For the use cases he presents it would make much more sense to subclass QRunnable then to subclass QThread. In my opinion in the use cases where he says its ok to subclass QThread, QRunnable would actually be the first choice.

              I'm not saying that there are no valid reasons for subclassing QThread, but in most cases you'd be better of using the worker object approach, even though it might be 10 lines of code more.

              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