0

I access the Qt GUI's QLabel's QPixmap in another thread since I will finally use this to display mjpeg stream in QLabel, and I decided to use QLabel since its the easiest way
It should look like 'Live' and not block the UI thus using another (non-gui) thread.

nothing shows up in the QLabel. only the exception QPixmap: It is not safe to use pixmaps outside the GUI thread
any better or correct way to do this ?
here is my PyQt code of another thread: self.theQlabel.setPixmap(QtGui.QPixmap.fromImage(myQimg)

vijiboy
  • 584
  • 11
  • 25

3 Answers3

2

Instead of directly setting the pixmap, make the external thread emit an updatePixmap signal. Then in the GUI thread, listen to the signal and update the pixamp at that time. Something like that should work (in C++):

// In the GUI thread:

class YourWidget: QObject {

public:

    YourWidget();

public slots:

    void updatePixmap(const QPixmap& pixmap);

}

YourWidget::YourWidget() {
    // Connect to the signal here:
    QObject::connect(otherThread, SIGNAL(updatePixmap(const QPixmap&)), this, SLOT(updatePixmap(const QPixmap&)));
}

YourWidget::void updatePixmap(const QPixmap& pixmap) {
    // Update the pixmap here in a thread-safe way
}


// In the external thread:

// Emit the signal. The GUI thread will receive it and can then update the pixmap
emit updatePixmap(thePixmap);
laurent
  • 88,262
  • 77
  • 290
  • 428
  • in a continuous (streaming) scenario, the Gui thread will be busy inside the slot for `updatePixmap`, effectively making it unresponsive. will it be so ? – vijiboy Jan 02 '12 at 14:50
  • 2
    Updating the GUI from a non-GUI thread is not possible and is more than likely to cause all kinds of problems and crashes. The solution given here will not work unless the connect call is changed to use a Qt::QueuedConnection, which will cross thread boundaries and execute the slot from within the GUI thread. – Chris Jan 02 '12 at 15:48
  • 1
    @vijboy, I assume the time consuming operation is to build the QPixmap, and this is done in the external thread. Assigning this pixmap to a label shouldn't take long. – laurent Jan 03 '12 at 04:12
  • @Laurent, absolutely. I will try this now. but anyways a thread-safe access to GUI elements should be a feature of any modern graphics library isn't it... – vijiboy Jan 03 '12 at 04:32
2

I think that it might be dangerous to even create a QPixmap in anything other than the GUI thread. You might want to consider passing a QImage and converting it to a QPixmap in the main thread. I can't find a direct reference to support this assertion, but

http://developer.qt.nokia.com/doc/qt-4.8/thread-basics.html

hints that

All widgets and several related classes, for example QPixmap, don't work in secondary threads.

The email thread at

http://lists.trolltech.com/qt-interest/2008-11/msg00534.html

also seems to agree with me.

seeker
  • 1,136
  • 1
  • 13
  • 16
  • converting `QImage` to `QPixmap` at 30 FPS for HD images in the main thread just for the display. I feel bad about loading main thread for video purposes. Are there any standard practices to it... ? – vijiboy Feb 21 '12 at 16:20
  • thanks for specifically pointing out that the making display dependent `QPixmap` out side gui/main thread is source of problems including crashes – vijiboy Feb 21 '12 at 16:23
  • @vijiboy The problem is that the "conversion" process might involve say, updating an OpenGL texture (if you're using an appropriate renderer). So I feel your pain, but don't know of a way in general to get around this. Please let me know if you figure it out :-). – seeker Feb 22 '12 at 17:28
1

Create RAW DirectX/OpenGL OS context into this QLabel's winId() and do whatever you want. I think, this is the best way for high performance HD video, and the ONLY way :) sometimes you just HAVE to use RAW things to achieve the maximum performance and touch the iron in your computer :)

Петър Петров
  • 1,966
  • 1
  • 17
  • 14