QImage and Qt 4.5.3

Hi;
I developped an application drawing images using QPainter.
First on OpenSUSE 11.0 with Qt 4.4.0, and it WORKS and print pictures, but have warnings for each picture I print.

Code:

---

QPixmap: It is not safe to use pixmaps outside the GUI thread
X Error: RenderBadGlyphSet (invalid GlyphSet parameter) 160
  Extension:    148 (RENDER)
  Minor opcode: 25 (RenderCompositeGlyphs32)
  Resource id:  0x0

---

Second on Ubuntu 9.10 with Qt 4.5.3 it diden't work, and didnt print anything with the same warnings.

Here is the code of paintEvent methode of the Widget I want to paint.

Code:

---

void paintEvent(QPaintEvent *event){
 
		const QPoint point(100,100);
		QImage image(pictureBuffer, width, height, QImage::QImage::Format_RGB888);
		QPainter painter;
		painter.begin(this);
			painter.drawImage(point,image);
		painter.end();
       }

---

Thank you for helping.

What is pictureBuffer? What does it contain? How is it populated?

pictureBuffer is an unsigned char array containing RGB pixels.
in OpenSUSE + Qt 4.4, it displays the content of the buffer with no problem.
The display is done by another Thread, I ll try to draw with the main thread to see

I tried to Draw with the main thread an it works. But it didnt match what I want.
This application is a video player.
I Have a main thread who creates a mainwidow where I have a Panel to display the Video and Buttons (Play, Pause,...)
Then I create 2 threads; one to make the pictures to the other who displays them.
So, If the work done by the second thread is done by the main thread, it works but I cant Access the buttons.
Thats the probleme
thank you for any suggestion

What do you mean exactly by drawing in the other thread? What are you drawing there? The widget?

Yes
The main window contains the widget where I draw the pictures. This widget implements the paintEvent methode like I say it first time.
I think the main thread (the GUI thread) is the only thread allowed to repaint the widgets.
Can we send signals between threads.
I ll try to modify the content of the buffer with The second thread , emit signal to the main thread to repaint.

Quote:

---

Originally Posted by halmassi

Yes
The main window contains the widget where I draw the pictures. This widget implements the paintEvent methode like I say it first time.

---

Ok but how do you update it in another thread? Could we see the code for that?

Quote:

---

I think the main thread (the GUI thread) is the only thread allowed to repaint the widgets.

---

Yes, that's correct.

Quote:

---

Can we send signals between threads.

---

Yes, we can.

Quote:

---

I ll try to modify the content of the buffer with The second thread , emit signal to the main thread to repaint.[/SIZE]

---

That's a good approach.

The code of the thread is lot of calculations, but we can resume it in :

Code:

---

while(!EOS)
             {
               actual_picture = this->Decoder->getNextPicture();
               this->Picture->repaint();           // to be changed into : emit draw()
            }

---

Picture is the widget drawing the pictures.
Decoder : global variable decoding a stream. EOS: end of stream
actual_picture is a global variable: the actual picture to be displayed.

I tried to use signals like I said. I added the signal draw(), and the slot drawPic():

Code:

---

void drawPic(){
               this->Picture->repaint(); 
            }

---

But this solution is not correct :
The second thread gets pictures and modifies actual_picture many times before the signal is handeled by the GUI thread.
So we have less pictures displayed than decoded.

It's enough to do update() instead of repaint() and painting will be done in the main thread. You don't need any signals or anything for that. But be aware that you are accessing the same variable (the image) from two threads, you need to do proper thread synchronization (or transfer the image between threads using events or signals which will provide synchronization for you at the expense of some overhead).

Ok, I used the signals to transfer the images between the threads
But the number of signals handeled is still < to the emitted.
I thought that signals are stored in some of queue and they'll be all handeled. am I wrong?

How can I wait, in the second thread, the termination of the display in the GUI thread for each picture.

Quote:

---

Originally Posted by halmassi

But the number of signals handeled is still < to the emitted.

---

Maybe you are generating them faster than they can be processed.

Quote:

---

I thought that signals are stored in some of queue and they'll be all handeled. am I wrong?

---

They are.

Quote:

---

Originally Posted by halmassi

How can I wait, in the second thread, the termination of the display in the GUI thread for each picture.

---

There are many ways, for instance you can use a wait condition (QWaitCondition) to wait on a mutex. But what exactly is the point of doing that?

Quote:

---

Maybe you are generating them faster than they can be processed.

---

Yes. thats correct.

Quote:

---

But what exactly is the point of doing that?

---

Because I generate pictures faster than I display them, I want to
generate signal with the picture
wait until the GUI thread displays the picture.
generate next signal with picture.

I dont know if it is the best way to solve the probleme

It's ok. Use a wait condition to protect the shared resource. You don't even need signals at all.

Its OK,
but I used a mutex instead of waitcondition, and I kept my signals.

Second THREAD:
-- get picture
-- send signal with the picture
-- block on mutex

GUI Thread Slot:
-- display picture
-- wake up 2nd thread

thanks wysota

If that's all you did then it's kind of wrong. You should wake the other thread before you display the picture and you should do that only if the picture to display changed since the last time you displayed it. Otherwise you might be releasing an already released mutex or blocking the other thread unnecessary.

No it works. Perhaps I didnt explain very well.
The GUI thread displays the picture only if he had received a signal from the other thread.
receiving the signal means two things: 1) the picture had been changed by the other thread, 2) the thread sending the signal is blocked on the Mutex
So when the GUI thread finishes displaying he woke up the other thread.

Quote:

---

Originally Posted by halmassi

No it works. Perhaps I didnt explain very well.

---

The fact that it works for situations you test it against doesn't mean it will work in every conditions.

Quote:

---

The GUI thread displays the picture only if he had received a signal from the other thread.

---

What if you resize the widget or obscure it with another window? It will get paint events. Won't it interfere with your mechanism?

The mutex mecanism is in the slot drawPic() witch works only with the signal draw();
So, other painting events causes repainting widget using paintEvent(); and will repaint the last picture
and no mutex is touched. We cant release a mutex already released and same with locking it.
I ll test these conditions to know the results.

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

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

Code:

---

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, ...);
}

---