View Full Version : Fastest PaintDevice?

7th November 2007, 19:50
I am wondering what the best (fastest) paint device would be for my application. I am doing the following: I get a couple of images via http requests. Those I store as QPixmaps. Then I draw these pixmaps into a larger pixmap to get a "composed" image. To display this image I call painter.drawPixmap(composedPixmap) within the paintEvent of the Widget. Is this the fastest way to realize this? I don't exacly know if a QImage could be faster.

Instead of using drawPixmap in the paintEvent of the widget bitblt() would surely be faster, but before I can use this, I have to convert the QPixmap into a QImage, and I don't think that's worth it.

Then... another question how do I performant move this composed image on the display? Do I give the "scrolling value" when calling drawPixmap()? I realised, this is faster than using painter.translate(). What about the performance of painter.setViewport()? (I would try this later myself, but I think if I'm already asking so many questions... ;))

If anybody have links for performant graphic programming on a Qtopia device I would be very happy to get them.

7th November 2007, 21:17
Can't you keep only that composed pixmap?

8th November 2007, 09:07
Yes, that composed pixmap also acts as my offscreen image. I forgot to tell, that I often have to redraw this composed pixmap depending on the user input.

8th November 2007, 15:46
On X Windows QPixmap is kept on the server, so drawPixmap() is the fastest way to display it. On M$ windows, QPixmap is practically the same thing as QImage (from OS's point of view). I'm not sure how exactly it's implemented in case of Qtopia, but QPixmap is designed for displaying, while QImage --- for per-pixel modifications.

In case of performance problems, make sure you draw and display only what you have to --- ask QPaintEvent what part of the widget needs to be updated. View transformations might cost you a lot, because the image has to be rescaled each time you draw it, although it might be accelerated by hardware.