Re: [Traverso-devel] Some QGraphicsView (the canvas) problems

[Nicola Doebelin]

Am Samstag, 10. Februar 2007 18:53 schrieb Remon:
> As you know, there has been some babbling going on here about painting
> performance, or the lack of it.
>
> The painting overhead for the playhead is insignificant, and perhaps a
> triple buffer approach can make it even more insignificant.
>
> Zooming however has doubled the cpu usage, which is correct, currently
> zooming generates 2 paintevents!
>
> I'm sorry for the trouble, and you was right to make note of this Nicola,
> it could in fact have been gone by unnoticed due me thinking it was a xorg
> problem.
>
> There are some more issues that cause unwanted repaints, I'll investigate
> why this happens (no luck so far), eventually send a problem report about
> this to trolltech, and hope the best for it.
>
> (Or burn the damn thing to the ground, and use another canvas that does
> what it advertises it should do!!!!!!)

If it is really a Qt problem, then I think it would be fair to inform 
Trolltech and try to find out if they are able to solve it. They seem to put 
a lot of work into QGraphicsView and I reckon they would appreciate some 
information from the developer base as to performance issues. If improvements 
from the Qt side are to be expected, you (Remon) should IMO leave further 
painting optimizations for now and wait until Qt has caught up. Putting a lot 
of work into an alternative implementation, just to find out that Qt has 
improved in the mean time, would be a huge waste of effort. After all on 
up-to-date PCs it works quite ok now, and even on my PPC I got some 
surprising numbers:

Performance test using 32 stereo tracks (44100 Hz/16bit stereo wave files) on 
a PowerPC G4 866 MHz, 640 MB RAM, 40 GB hard disk at 4200 rpm. Traverso was 
compiled in release mode with Qt 4.2.2 (stable release).

A song with 32 stereo tracks was created, and using the SOLO function, the 
number of tracks playing back was increased stepwise. At track no. 26 the 
hard disk gave up and I got buffer underruns. The CPU load of traverso in top 
was 60% at that point. No curves were active.

Zooming is very slow even with low numbers of tracks. With 32 it didn't become 
significantly slower. Xorg load depends on the horizontal zooming level. For 
this test the visible range was approx. 3 minutes so as to have low Xorg CPU 
load.

All in all much better numbers than I had expected.

Nice sunday everyone!
Nic