Re: [Traverso-devel] playhead cpu usage, crosshair like implementation needed ?

[Remon]

> I must admit I'm surprised (or disappointed for that matter) by the poor
> performance of QGraphicsView. After all it is advertised as a very
> powerfull framework, designed to work with large numbers of 2D objects.

There has been an extremely lengthy discussion on qt4-preview mailinglist on 
exactly this issue.

To clarify things a bit:

QGraphicsView doesn't paint _at all_ !
It manages in combination with QGraphicsScene the graphics items, and it's 
doing a _great_ job at that, no doubt!

The painting is done by the arthur paint engine, which is called by the 
ViewItems, like painter->drawRect(), painter->drawLines() and so on, so to 
some degree, we have to blame that piece of code ?
Unfortunately, it's not that simple. We the user want vector based drawing, so 
the engine has to be vector based.
This imposes a certain amount of overhead!
This overhead is reduced to some very little cpu load in Qt 4.3, so that's 
very good news.

Why does painting then still take so much cpu time? 
What became clear on that lengthy discussion on qt4-prevew ml is that the very 
same application that took ~ 80% cpu load in X11 only took ~ 5% max on 
windows .....

Conclusion? Let's burn xorg LOL
Nah, they are really working hard to make xorg a better place, erm, program. 
But you all know how good video drivers are in linux, and xorg (or better 
xfree86 in it's days) is years behind in development, so it takes time to 
catch up....

> Have you reported your problems to a Qt specific list (e.g. qt-interest) or
> forum (e.g. www.qtforum.org)?

Ah, no, but as you see, they are aware of it, and it's unlikely they can do 
much about it ....
Would be interesting to compile traverso on windows and see how it performs. 
Anyone?
(Install Qt 4.2 on windows using mingw, run qmake in traverso dir and all 
should be fine)


> Just an idea (although you probably tried this already): QGraphicsView
> inherits from QWidget, so you should be able to bypass the QGraphicsScene,
> paint directly on the widget and use 2 pixel wide buffers. 

That's what I tried yesterday, but that solution destroys a good deal of the 
flexability what the qt backingstore gives us, as well as the powerfull 
functions of the graphicsview framework.
As explained above, the cpu hogging isn't due qgraphicsview itself....

> With the current 
> solution the CPU usage depends on the number of clips beneath the play
> head. 
> Would a dual core CPU ever be able to cope with a >24 track project? 
> If you paint on the widget, CPU usage would depend on the window size, and
> actually be no issue for such a small number of pixels.

Using Qt 4.3:

Traverso: ~ 18% 
Xorg: sometimes 0, sometimes ~ 17% 

Tracks displayed: 27, all with clips of course :-)

Load on animated scroll : 

Traverso: ~ 25%
Xorg: ~ 10 - 18 %


So the short answer: Yes.
Long answer: I hate it when something so simple as a play cursor consumes this 
much processing power!


Summarizing: We hardly can blame Qt for this problem, if we can make the 
triple buffering solution to work easily, would be great, and let's pray xorg 
and driver support in linux get a bit better :-)

Remon

P.S.
If you have the time, listen to this:
http://mirror.linux.org.au/pub/linux.conf.au/2007/video/monday/monday_1430_debian.ogg

Or read this summary:
http://lwn.net/Articles/218380/

If they can get this all somewhat up and running for xorg 7.3, then the future 
seems to be much brighter for xorg (and buy one of these decicated intel 
graphics cards :D )