bobrien
13th September 2011, 01:32
Hello All,
I'm having some difficulty getting slots residing in a QObject class that has been moved into a thread to actually execute in a separate thread.
I have read quite a bit on this, and found most examples, including the one here (http://labs.qt.nokia.com/2010/06/17/youre-doing-it-wrong/) to be slightly simplified....or at the very least different than my program.
I have (essentially) a UI that displays streaming video. The video is received from the camera, processed and marked up. It is then finally displayed on the UI (on a QLabel). The system is 100% functional. However, I've realized that the speed of exposing and transfering the images from the camera at a high rate (>30fps) is causing substantial delay in my UI responsiveness. The processing part is "correctly" threaded to the point that it doesn't affect UI performance (although it may be re-evaluated if I solve this issue) - I mention this because it was done using the older, and supposedly now frowned upon method of subclassing QThread and re-implementing run().
Where this appears to be different from the examples provided is that rather than creating the QThread objects in some sort of main() function, I create them in the constructor for my QMainWindow object. Then I want to connect a signal from the object I hope to move to the thread, to another object that remains in the current (main) thread. Something like:
class WindowApp : public QMainWindow
{
Q_OBJECT
WindowApp()
{
myObject = new myObject();
otherObject = new OtherObject();
QObject::connect(myObject, SIGNAL(mySignal()), otherObject, SLOT(handleMySignal()));
camera_thread.start();
myObject->moveToThread(&camera_thread);
}
private:
QThread camera_thread;
MyObject* myObject;
OtherObject* otherObject;
};
class MyObject : public QObject
{
Q_OBJECT
MyObject();
signals:
void mySignal;
};
class OtherObject:: public QObject
{
Q_OBJECT
OtherObject();
public slots:
void handleMySignal();
};
The result of running this code is a completely functional application, except that when examining the process ID's of the various functions/slots being called, I can see that (in particular) the slot handlyMySignal() is being executed in the same thread as both the WindowApp constructor and other (not shown here) slots in MyObject.
After quite a bit of reading, I believe this to be because the QThread camera_thread is owned by WindowApp (which is effectively my "main" thread). The net result is anything happening in handleMySignal() causing the UI to be delayed, due to (I believe) the connection type being modified from queued to direct.
So my question, finally, is in this scenario how can I define a new thread, move an object to it, AND have that objects slots be executed in the new threads context?? This seems like it shouldn't be that hard, or that uncommon, yet I am stumped.
Thanks in advance,
Barry
I'm having some difficulty getting slots residing in a QObject class that has been moved into a thread to actually execute in a separate thread.
I have read quite a bit on this, and found most examples, including the one here (http://labs.qt.nokia.com/2010/06/17/youre-doing-it-wrong/) to be slightly simplified....or at the very least different than my program.
I have (essentially) a UI that displays streaming video. The video is received from the camera, processed and marked up. It is then finally displayed on the UI (on a QLabel). The system is 100% functional. However, I've realized that the speed of exposing and transfering the images from the camera at a high rate (>30fps) is causing substantial delay in my UI responsiveness. The processing part is "correctly" threaded to the point that it doesn't affect UI performance (although it may be re-evaluated if I solve this issue) - I mention this because it was done using the older, and supposedly now frowned upon method of subclassing QThread and re-implementing run().
Where this appears to be different from the examples provided is that rather than creating the QThread objects in some sort of main() function, I create them in the constructor for my QMainWindow object. Then I want to connect a signal from the object I hope to move to the thread, to another object that remains in the current (main) thread. Something like:
class WindowApp : public QMainWindow
{
Q_OBJECT
WindowApp()
{
myObject = new myObject();
otherObject = new OtherObject();
QObject::connect(myObject, SIGNAL(mySignal()), otherObject, SLOT(handleMySignal()));
camera_thread.start();
myObject->moveToThread(&camera_thread);
}
private:
QThread camera_thread;
MyObject* myObject;
OtherObject* otherObject;
};
class MyObject : public QObject
{
Q_OBJECT
MyObject();
signals:
void mySignal;
};
class OtherObject:: public QObject
{
Q_OBJECT
OtherObject();
public slots:
void handleMySignal();
};
The result of running this code is a completely functional application, except that when examining the process ID's of the various functions/slots being called, I can see that (in particular) the slot handlyMySignal() is being executed in the same thread as both the WindowApp constructor and other (not shown here) slots in MyObject.
After quite a bit of reading, I believe this to be because the QThread camera_thread is owned by WindowApp (which is effectively my "main" thread). The net result is anything happening in handleMySignal() causing the UI to be delayed, due to (I believe) the connection type being modified from queued to direct.
So my question, finally, is in this scenario how can I define a new thread, move an object to it, AND have that objects slots be executed in the new threads context?? This seems like it shouldn't be that hard, or that uncommon, yet I am stumped.
Thanks in advance,
Barry