Qt3 more fast than Qt4 ?

[commarmi]

Hello,

I created an application that draws 10000 lines in canvas, it allows to move the lines with the mouse.

Qt3 works well but Qt4 is slow.
I enabled Opengl with Qt4 but is more slow than whitout.

I attache a zip with 2 versions (qt3 and qt4).

is Qt3 more fast than Qt4 ?

Thanks

[Bitto]

Sometimes yes, sometimes no. The two APIs QCanvas and Graphics View are similar enough in behavior and API to be compared like this, that's only reasonable. But the same code might not be as fast in one as the other, although often tweaking the slow one will bring them up to the same level. This is no exception.

In your example, you've got 10000 line items on top of each other. This is the absolute worst-case scenario for a BSP tree, which is what Graphics View uses for indexing. If you run a profiler, it'll show that most of the time is spent in the BSP tree.

First, the fastest the program can start, show itself, and then quit, is today 4.5 seconds on my machine using Qt 4.3. With Qt 3.3, this is 1.2 seconds. Now,



scene.setBspTreeDepth(6); // seems to be optimal for your app


Now it takes only 0.8 seconds with 4.3, a 5.6x speedup. That's 50% faster than Qt 3. You should notice right away that the Qt 4 app starts faster than the Qt 3 one.

Now, you're creating lines that have a width of 1. In Qt 3, line items were just drawn as cosmetic lines (startpoint, endpoint). In Qt 4, line items follow the same capping rules as QPainter lines, and they transform properly. Try zooming in in the Qt 3 example, you'll see the lines don't get any thicker, but in Qt 4 they do. Their shape gets slightly more complex with Qt 4 also, because the shape of a line in Qt 4 is 100% accurate, whereas in Qt 3 a QCanvasLine's area was only estimated roughly. Try setting a cosmetic pen instead of a normal pen in Qt 4:



i->setPen( QPen(QColor(qrand()%32*8,qrand()%32*8,qrand()%32*8 ), 0) );
// notice pen width == 0


Because the cosmetic pen shape is so simple, and this is equivalent to QCanvas' behavior, you get close to a 10x speedup. Now the example runs at approximately the same speed in Qt 4 as in Qt 3.

There's still some things that can be optimized further in Qt 4, your example serves as a very nice benchmark. If you still find the example is slow, do like me and run a profiler on it (I recommend valgrind --tool=callgrind, and kcachegrind for visualizing the results).

[wysota]

Andreas, I admit - this is a very nice piece of explanation. Trolltech should do some trainings in Qt internals and quirks, not only demonstrating the API. Do you intend to show such things as the one above during DevDays (sorry for the offtopic)?

[marcel]

Andreas, I admit - this is a very nice piece of explanation.
But of course it is. The man wrote the damn thing, didn't he?

[wysota]

But of course it is. The man wrote the damn thing, didn't he?

That's not the point. The point is he is willing to share his knowledge. Of course we could browse the sources, etc. but that takes time and he already knows the sources by heart ;)

[Bitto]

I'll try to find some time to talk about making things fast, but it's pretty hard to generalize on it since it's so specific to the application at hand :-). Still, it's a 2.5h talk... there should be some room for it. I also try to update the documentation whenever I come across benchmark apps like this, too. Nobody likes hidden slowness, or "fastness" for that matter...

[Uwe]

Sometimes yes, sometimes no. The two APIs QCanvas and Graphics View are similar enough in behavior and API to be compared like this, that's only reasonable. But the same code might not be as fast in one as the other, although often tweaking the slow one will bring them up to the same level.

But both sit on a QPainter. In Qt3 QPainter was a thin wrapper around the native graphics library ( X1, ...), in Qt4 we run through Arthurs render pipeline.

Although the performance of Qt4 has been improved a lot from Qt 4.0, Qt4 applications feel fat. ( F.e. when scrolling an empty scroll area, the handle of the scroll bar can't follow mouse movements. ) The new release of our product has recently been ported to Qt4, what makes it possible to compare - and the result is not very appealing.

I remember a discussion at the first Trolltech Days, where I was told, that the effects of modern desktops have priority and the performance issues will be obsolete, because of hardware improvements. But today people (including me) are looking for fanless, less power consuming office systems.

Uwe

[commarmi]

Thanks Bitto for your help.

Really now is more fast.

[commarmi]

But,

why with opengl is more slow ? I'm testing on:
Pentium4 1.70GHz
1Gb of Ram
GeForce4 MX 440 AGP 8x

Gentoo Linux 2007.0
xorg 1.3.0
NVIDIA Linux x86 Kernel Module 1.0-9639
glxgears = "1181.034 FPS"

only add "setViewport(new QGLWidget(QGLFormat(QGL::SampleBuffers)))" on my code. Is it correct ?

[wysota]

But both sit on a QPainter. In Qt3 QPainter was a thin wrapper around the native graphics library ( X1, ...), in Qt4 we run through Arthurs render pipeline.

Although the performance of Qt4 has been improved a lot from Qt 4.0, Qt4 applications feel fat. ( F.e. when scrolling an empty scroll area, the handle of the scroll bar can't follow mouse movements. ) The new release of our product has recently been ported to Qt4, what makes it possible to compare - and the result is not very appealing.

I think you can tweak around things a little, disabling the backing store, for instance. I'm currently experimenting with a simple animated widget and disabling composition caused a vast improvement in cpu usage (though it was the X server that reported high usage, not the application itself). I guess there are more improvements to be applied, it's just not that obvious where they are. That's why a training like the one I mentioned could be helpful.

Besides that, computers change and we, the developers, have to adjust to that. Multicore processors are becoming standard nowadays, but an application has to be specially designed to make use of the technology. Otherwise it'll run slower instead of being faster due to the way multi-core works.

[Bitto]

OpenGL requires you to redraw everything in the viewport always. There's no such thing as a partial update, scroll optimization, and so on. So with a native painter, when you scroll horizontally the only area that's redraw is the 1-pixel vertical line at the right-most or left-most part of your viewport. The rest is just shifted. This isn't possible with QGLWidget - every time something changes, everything is redrawn.

Why QGLWidget cannot draw 10000 lines at real-time / 25fps, should just be a matter of running a profiler though. I'm sure something will show up that will point you in the right direction.

[commarmi]

Ok, thanks.

I will compile Qt with debug info and run profiler.