Hello,
I'm writing a viewer application that needs to render bitmaps in different ways. At the moment, I'm thinking of standard QImage/QPixmap operations and xvideo overlay.
I'd like to hide the differences in a QWidget-derived class. ( That is either having a base class defining the interface and two derived classes, or a single class with both standard and xvideo rendering functionality).
My problem is that I need some cpu time for format conversions, which I'd like to keep away from the gui thread. My image source provides frames in its own format, that need to be more or less converted, depending on the rendering mode.
Im basically thinking of a class with this interface:
Qt Code:
{ public slots: void newImage( some_image_struct* pImg ); }To copy to clipboard, switch view to plain text mode
New images should be announced by a signal connected to "newImage". On signal reception, image data needs to be processed by a worker thread. When using the standard rendering method, results need to be copied to a QPixmap which is then painted by the next paintEvent call.
This is what I have in mind - but Im not sure about the details. My main problem is that I dont have little in-depth knowledge about signals, slots and threads.
My questions:
- Ive read that I can move QObjects from one thread to another, so that slot functions are executed in the new thread's context. Can I legally move QWidgets to another thread? ( The overwritten paintEvent function should still be executed by the GUI thread, as paintEvent is not a slot. correct?)
- My QWidget-derived class should maintain its own thread for image conversion. Inheriting from both QWidget and QThread will not work, AFAIK. Im thinking of a QThread member inside my widget. So Im planning to have a QWidget derived class, which is, in terms of thread affinity, owned by one of its own members ( instance of QThread). Are there any problems with this idea?
- A more simple solution would be to have a Widget owned by the GUI-tread with a QThread-based member owned by itself. This way the widget's slots would be executed by the GUI thread. Nevertheless, GUI thread utilization can be minimized, as incoming signals only need to be forwarded to the worker thread member object. (Which then uses its own thread...)
This way, I would get a cleaner design, but I need one more slot to be triggered. Do I have to expect notable performance loss here?
And my last question: Do I miss any concept that makes things more easy for me?
Thanks for reading!
phixx
Bookmarks