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....
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....
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
I would say that the problem is simply hard to notice on better systems.
A not-so-random quote from the sources:
Qt Code:
timerId = startTimer( 1000 / 1000 );To copy to clipboard, switch view to plain text mode
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.
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).
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...
Bookmarks