Render from a thread into a pixmap?

[rage]

I have a thread which I use to render a QPixmap. Doing this I get errors from the Xlib. In this
forum I've already read the cause is that the X server manages the pixmaps and threads should not access them.
So I tried a QImage, which is pretty slow... I think it would be better to use no Thread and render in the GUI thread (which blocks), but is faster...

Is there any way to render within the thread into this pixmap?

[wysota]

You can only render to QImage from a worker thread and then you can convert it to a pixmap in the gui thread.

[rage]

This is very sad, because drawing a QImage is so much slower...

Is it possible to handle GUI events in another thread and do the expensive pixmap creation in the GUI thread? (Changing the tasks of the threads?) So the GUI should stay operable.

[wysota]

Is it possible to handle GUI events in another thread (...)
No. GUI must be handled from the main thread. So do pixmaps as they are related to the X server.


So the GUI should stay operable.

It's best to redesign your code using timers or QCoreApplication::processEvents(). I'm almost sure you can do anything you need without threads or blocking the application.

[jacek]

This is very sad, because drawing a QImage is so much slower...
What do you draw exactly? And how much is "much"?

[rage]

I combine up to nine RGB-images with a resolution of 256x256 each to one large image. I want to do this depending on user interaction multiple times a second. The combined QImage is created in the "worker" thread and gets converted to a pixmap in the GUI thread (by calling QPixmap::fromImage()). Here I draw it on the screen. The conversion from QImage to QPixmap with a resolution of eg 768x768 is the slowest operation I think.

[wysota]

If you do it several times a second, I suggest you draw it to the screen without composing it first on an offscreen bitmap. Or even use OpenGL.

[rage]

If you do it several times a second, I suggest you draw it to the screen without composing it first on an offscreen bitmap. Or even use OpenGL.

Currently I am playing with the QCoreApplication::processEvents() you mentioned. I think this could solve my problem. I am not using OpenGL, bacause the application should also run on Qtopia devices...

[jacek]

The conversion from QImage to QPixmap with a resolution of eg 768x768 is the slowest operation I think.
It could be, but you have said that drawing on QImage is slower than drawing on QPixmap. Have you tried to use a profiler to check the times?

[rage]

I could be, but you have said that drawing on QImage is slower than drawing on QPixmap. Have you tried to use a profiler to check the times?

Yes, I have done that with callgrind. The fromImage() call takes ~44% of the processing time.

[rage]

Thanks wysota!
I'm now rendering the QPixmap within the GUI thread, so I don't need QImages. By calling processEvents() it doesn't block. I'll just have to do some locking with mutexes and then everything should be fine!

[longtrue]

How rendering the QPixmap within the GUI thread? And how to do it won't be block?Would you mind write your handle?Thanks

[faldzip]

Read this: http://doc.trolltech.com/qq/qq27-responsive-guis.html.