graphicsview performance problem

[kernel_panic]

Hi all!
I have a problem with the performance of a QGraphicsView.
I made a small example and attached it. For the animation i have to do i need more than 1000 particles.
I tried it qith OpenGL viewport, optimazion flags and buffers. finally i put the particle system into a thread... nothing helped.
Im new with QGraphicsView and im sure some of you gurus can help me.

[wysota]

The example you provided works quite fast on my computer (with the GL viewport). Could you specify what exactly is the problem?

[kernel_panic]

try with 2000 particles.
int calcthread.cpp:
Init(2000,n_forces,f,Create,vel,pos1,pos2,128,QCol or(0,0,255,255),4);

[wysota]

I did. 2000 is still quite fast. With 10000 it's slow, but drawing 10k pixmaps is quite an effort, so I can understand it.

[kernel_panic]

?? for me is quiet slow....
and my dualcore has over 50% processor load.

[jacek]

Use a profiler. It will show you where you should improve your application.

[wysota]

I have a single core Athlon 2.5+ with hardware accelerated OpenGL implementation under Linux/X11 and Qt 4.3.3.

If rendering is too slow for you, try using OpenGL calls to render your items. It should be very fast - after all it's just a bunch of quads with the same texture applied.

[kernel_panic]

ah!
i forgott one thing!
on linux, bsd and mac its quiet fast... but under windows....puah!

you mean i should implement it fully in opengl? i never worked with opengl.... dou you know any good tutorials?

[jacek]

First try the profiler. By adding "const &" in certain place and changing one constant you can save about 30% of the CPU time.

[kernel_panic]

I never used a profiler.
i tried it with "sleepy", an oo project, but he said 47% of 50% processor load are from KiFastSystemCallRet.
WTF IS THAT? I think i know now why i hate developing under windows....

[wysota]

I suggest trying callgrind or gprof under Linux.

[Uwe]

I suggest trying callgrind or gprof under Linux.

Well, the problem was described as a Windows only problem.

Try to render the scene to a QImage, because QImage uses the same paint engine on all platforms, that is used on Windows. If you see the same performance problems with QImage/Linux you can use the tools Witold recommended.

Most paint engines are frontends to native paint subsystems like X11, but the raster paint engine is a new development in Qt4. So its no surprise, that many problems ( and performance issues ) are related to it.

Uwe

[jacek]

Well, the problem was described as a Windows only problem.

I would say that the problem is simply hard to notice on better systems.

A not-so-random quote from the sources:

timerId = startTimer( 1000 / 1000 );

timerId = startTimer( 1000 / 1000 );

To copy to clipboard, switch view to plain text mode 

[kernel_panic]

that was a test. normally its 1000/25 for 25 fps.
but it doesnt matter, if its 1 or 40. after 1500 particles the scene becomes pretty slow. and the processor load wents to the 50%.
i saw other particle systems with more than 9000 particles and more graphics, which didn't have such a performance problem.

[jacek]

that was a test. normally its 1000/25 for 25 fps.

That's better. What else did you change?

i saw other particle systems with more than 9000 particles and more graphics, which didn't have such a performance problem.

Then use a profiler and see what's eating your CPU power.

[wysota]

Well, the problem was described as a Windows only problem.

Try to render the scene to a QImage, because QImage uses the same paint engine on all platforms, that is used on Windows. If you see the same performance problems with QImage/Linux you can use the tools Witold recommended.

Most paint engines are frontends to native paint subsystems like X11, but the raster paint engine is a new development in Qt4. So its no surprise, that many problems ( and performance issues ) are related to it.

He is rendering to QGLWidget, so I doubt the OS matters when speaking about paint engines - all use the GL paint engine.

A profiler was suggested to be used to find a bottleneck within the application code and not Qt, so again the system doesn't matter - Jacek suggests putting some "const" modifiers so the influence of internals of the framework is minimal.

@kernel_panic: Were those systems painting pixmaps? I'm sure you can render several thousand particles when using pure OpenGL (not QPainter interface to the GL paint engine) and you can probably boost the performance even more by pushing some of the calculations to the GPU (for example using fragment programs).

[kernel_panic]

yeah. this sounds nice, but i dont know how to translate it into pure opengl. i never used it.
the examples i saw where in pure opnegl and rendered textures onto the particles. but i need it in a qt-app, so i cant use this code...