Image-based widgets showing is too slow in Qt 4.2.1

[mkrentovskiy]

Hi!

I developing the application with image-based widgets inherited from Qt abstract widgets.
This mean that I use QPixmap for drawing backgrounds or active elements of this widgets (don't ask me why I don't used Qt styles :))))

But when I try to hide one frame with this kind of widgets and show another I have a unpleasant flash (when the frame is hiding) and slow redrawing of the frame which must be shown. More unpleasant that I use 1280 x 1024 resolution - may be bitmaps too big for create double buffering in 2D.

How I can accelerate widget showing/hiding without using any hardware solutions?

[jpn]

Do you, by any chance, manipulate rendered images somehow during every paint event?

[mkrentovskiy]

Do you, by any chance, manipulate rendered images somehow during every paint event?

I just repaint bitmaps without any transformations. For example:


void Slider::paintEvent(QPaintEvent *)
{
QPainter painter(this);
QBrush brush(S_COLOR);
QPen pen(S_COLOR);

painter.drawPixmap(0, 0, *background);
painter.setPen(pen);
painter.setBrush(brush);
painter.drawRect(xs, yd, is - xs, js - yd);
}

[marcel]

Try increasing the pixmap cache, with QPixmapCache::setCacheLimit(int).
If I remember correctly you have to pass a number of kilobytes there. An 1280*1024 pixmap will automatically not be cached since the initial limit is 1Mb.

Next, maybe you can make some use for QPaintEvent::rect and update only the dirty area.

Regards

[marcel]

Also take a look at optimizing with pixmap cache: http://doc.trolltech.com/qq/qq12-qpixmapcache.html.

BTW, why don't you use tiles instead of really large images? tiles could be cached more easily.

Regards

[mkrentovskiy]

Try increasing the pixmap cache, with QPixmapCache::setCacheLimit(int).
If I remember correctly you have to pass a number of kilobytes there. An 1280*1024 pixmap will automatically not be cached since the initial limit is 1Mb.

I increased cache limit up to 32Mb but flash in show/hide-operations still going on. :( But redrawing is a faster subjective. :)


Next, maybe you can make some use for QPaintEvent::rect and update only the dirty area.

Its right but not for total widget repainting when all visible area are dirty.

[marcel]

Its right but not for total widget repainting when all visible area are dirty.

Yes, but at least you can get faster updates for smaller dirty areas.

Regards

[mkrentovskiy]

Yes, but at least you can get faster updates for smaller dirty areas.
I agree with you, but in this case application will be shown over any window (for touchscreen purposes).

[mkrentovskiy]

Marcel, thank you for link.



BTW, why don't you use tiles instead of really large images? tiles could be cached more easily.
What is it? Where I can read about it?

[marcel]

Well, not sure where you can read about it.
Tiles means splitting the bigger image into smaller rectangles(tiles) and draw them in the paint event.

Although, now that you said that your app is always on top, not sure how is this going to help you.

Maybe drawing is faster if you use a graphics view or a gl widget? But I don't know if that suites you.

Regards

[mkrentovskiy]

Maybe drawing is faster if you use a graphics view or a gl widget? But I don't know if that suites you.
Ok, I try to experimented with it. Thanks for your help. :)

[wysota]

I agree with you, but in this case application will be shown over any window (for touchscreen purposes).

That doesn't mean anything. If you have a widget that contains a button and you push that button, the parent widget will probably receive a paint event as well for the rectangle that contains the push button. So partial paint events may still occur.