[Qt-jambi-interest] QPixmap erratic performance

[Gunnar Sletta]

Bart van Deenen wrote:
> On Monday 17 November 2008 09:07:03 you wrote:
> 
>  > Bart van Deenen wrote:
> 
>  > > Hi all
> 
>  > >
> 
>  > > I'm constructing a display from a nested tree of objects, each of which
> 
>  > > contains two QPixmaps for visual effects stuff. The whole code works
> 
>  > > fine (as
> 
>  > > far as display content is concerned), but the performance is very
> 
>  > > erratic. One function that contains two consecutive drawPixmap calls on
> 
>  > > the same QPainter might take between 4 and 100 ms.
> 
>  > > I've read somewhere on the web about a maximum QPixmap storage (can't
> 
>  > > find where anymore). Is this what I'm running against? Is the operating
> 
>  > > system (Linux in my case) or the graphics driver doing something? I 
> don't
> 
>  > > think it's
> 
>  > >
> 
>  > > my code, its just a single thread.
> 
>  >
> 
>  > On Linux the time spent doing a drawPixmap is mostly sending a command
> 
>  > to the X server and returning immediately. The actual drawing happens in
> 
>  > a different process and is not visible unless the application does a
> 
>  > QApplication::sync().
> 
> I'm creating them once. They're static between calls.
> 
>  > Are you creating these pixmaps on the fly or are they static between 
> calls?
> 
>  > If there is sporadic time differences, my best guess would be that GC is
> 
>  > kicking in frequently. Do you have a lot of allocations in your code?
> 
> Hardly any (just a few QRects and QPoints. I don't think it's the gc.
> 
>  > On Windows back in the Qt 3 days, QPixmaps used GDI objects which was a
> 
>  > pool of 10k objects per process. If the total number of fonts, pixmaps,
> 
>  > icons, windows etc grew beyond 10.000 the process would start behaving
> 
>  > "weird". This is much less a problem in Qt 4 as neither pixmaps, icons
> 
>  > nor windows use native GDI handles anymore.
> 
> I'm trying to narrow it down, but can't find it yet. My mainloop code is:
> 
> public void paintEvent(QPaintEvent g) {
> 
> // does all the combination of QPixmaps into one (root.pixmap)
> 
> this.render(root);
> 
> QPainter painter = new QPainter();
> 
> painter.begin(this);
> 
> painter.drawPixmap(10, 30, root.pixmap);
> 
> painter.end();
> 
> }
> 
> protected void timerEvent(QTimerEvent event)
> 
> {
> 
> if (event.timerId() == timer.timerId()) {
> 
> update();
> 
> }
> 
> else {
> 
> super.timerEvent(event);
> 
> }
> 
> }
> 
> Ok. I'm starting to get somewhere. I've added instrumentation to the 
> code (not shown here) which uses System.currentTimeMillis() to measure 
> intervals, and it turns out that the interval between two consecutive 
> calls to timerEvent is very erratic! My 'render' function (currently 
> with a much simplified QPixmap tree under it) only takes a few ms. The 
> QTimer is supposed to run at 40 ms interval, but the actual intervals 
> are anywhere between 15 and 300 ms!

A timer tries to fire as close to, but at least 40 ms after the last 
one, but there are no guarantees. I've never seen such behaviour, so I 
would have to see your code to know more..