QImage and Qt 4.5.3

[wysota]

Can you show us the code from both threads that accesses the mutex?

Here is a mutex-free implementation, by the way:

connect(worker, SIGNAL(newImage(QImage)), widget, SLOT(drawPic(QImage)), Qt::BlockingQueuedConnection);
//...
void Widget::drawPic(QImage img){
  m_image = img;
  update();
}
 
void Widget::paintEvent(QPaintEvent *pe){
  QPainter p(this);
  p.drawImage(m_image, ...);
}

connect(worker, SIGNAL(newImage(QImage)), widget, SLOT(drawPic(QImage)), Qt::BlockingQueuedConnection);
//...
void Widget::drawPic(QImage img){
  m_image = img;
  update();
}

void Widget::paintEvent(QPaintEvent *pe){
  QPainter p(this);
  p.drawImage(m_image, ...);
}

To copy to clipboard, switch view to plain text mode 

[halmassi]

/*initialisation*/
      pthread_mutex_t Mutex;
      pthread_mutex_init(&Mutex,NULL);
      pthread_mutex_lock(&Mutex);   // init to 0
 
      connect(worker, SIGNAL(newImage(QImage)), widget, SLOT(drawPic(QImage)), Qt::BlockingQueuedConnection);
      //...
      void Widget::drawPic(QImage img){
      m_image = img;
      update();
      pthread_mutex_unlock(&Mutex);
      }
 
      void Widget::paintEvent(QPaintEvent *pe){
      QPainter p(this);
      p.drawImage(m_image, ...);
      }
 
     void worker:: play(){
         while(condition){
            QImage img = decoder->getImage();
            emit newImage(img);
            pthread_mutex_lock(&Mutex); //block until waked by widget
       }
      }

/*initialisation*/
      pthread_mutex_t Mutex;
      pthread_mutex_init(&Mutex,NULL);
      pthread_mutex_lock(&Mutex);   // init to 0

      connect(worker, SIGNAL(newImage(QImage)), widget, SLOT(drawPic(QImage)), Qt::BlockingQueuedConnection);
      //...
      void Widget::drawPic(QImage img){
      m_image = img;
      update();
      pthread_mutex_unlock(&Mutex);
      }

      void Widget::paintEvent(QPaintEvent *pe){
      QPainter p(this);
      p.drawImage(m_image, ...);
      }
      
     void worker:: play(){
         while(condition){
            QImage img = decoder->getImage();
            emit newImage(img);
            pthread_mutex_lock(&Mutex); //block until waked by widget
       }
      }

To copy to clipboard, switch view to plain text mode 

[wysota]

Is that your code or mine? BTW. There is QMutex, you know. And if you are using a blocking queued connection the mutex is not required (provided that "worker" lives in the worker thread). Either way this solution is inefficient - your worker threads will continue to produce images regardless of the widget being able to refresh itself. update() schedules a repaint and if two update() calls occur before the repaint is actually done, they are merged into one. So it is likely to happen that you will produce 10 images but only display the last one.

[halmassi]

I used your code to resume mine.

I prefer use the Posix threads and mutexes.

How can we use a blocking queued connection.

The worker cant produce several images without displaying them all.
Because, After the first image he will block on the mutex until Widget wake him

[wysota]

I used your code to resume mine. :)

I prefer use the Posix threads and mutexes.

That's what Qt uses too but it gives you a nicer interface.

How can we use a blocking queued connection.

If you are not using QThread then you can't.

The worker cant produce several images without displaying them all.
Because, After the first image he will block on the mutex until Widget wake him

No, that's not true. This is because the worker thread is woken up directly after a call to update(). And a call to update() doesn't cause the widget to be painted. So the following sequence of events may happen:

worker::newImage()
widget::drawPic()
widget::update()
worker::newImage()
widget::drawPic()
widget::update()
worker::newImage()
widget::drawPic()
widget::update()
worker::newImage()
widget::drawPic()
widget::update()
worker::newImage()
widget::drawPic()
widget::update()
widget::paintEvent() <- here the widget is repainted

Especially if you're not using QThread...

[halmassi]

Ok thanks, You are Right.
Now I understand.
so you think, it will be better to switch to QThread.
I have another aspect of the application, where I create several Threads (the number of threads is known at the execution)
dynamicaly but using the same function:
How can I do that with QThread.

[wysota]

You can subclass QThread and reimplement its run() method. Remember to push the QThread object into its own thread using QObject::moveToThread() (search the forum for details on what it does and why it's needed). You can then use blocking queued connection to obtain the same effect you have now or use a mutex and optionally a wait condition to make sure the worker thread is activated only after the image is really painted.

[halmassi]

Ok, I ll spend time to switch to Qthread.
We close this thread, and I ll be back in few days.
Thanks for all wysota.