I have a bunch of OpenGL experience, and a bunch of Qt experience, but I’ve never used the two together…
What I can tell you about qt is that the signal/slot mechinism should be very fast. Not too much different than a function call.
I imagine that your opengl call routine is connected to a qt timer? Maybe you could reduce the time on that timer. If you bring it down to zero, you may even go back to using 100% of your CPU!
Reducing too much the timer value actually slowed performance. QT starts throwing signals, and that slows things, I keep assuming.
And sorry if I was not clear. Not using 100% CPU is a good thing. I’m using Nvidia drivers that have a kernel issue previously discussed on this same forum that makes them to spend near 100% CPU; adding a slight latency before the drawing fixed that, and slightly slowed performance too.
I don’t know if this is fixed in recent versions of Qt, but we experienced a performance problem due to QGLWidget updating* the OpenGL context every frame. This was slowing performance on the Mac by about half, and Linux noticeably.
The fix was only a couple of lines of code, basically not updating the context if the one you’re about to render to is already the current context.
Updating in the sense of resizing the surface (usually to its existing size), changing swap regions, &c.
QGLContext::makeCurrent(): Cannot make invalid context current.
errors; it’s possibly making a current context every frame.
How did you turned off that? Overriding a function? I can’t quite figure that.
<added> All right, I confirmed it. Overriden and augmented QGLWidget::makeCurrent() to make it print a message, it is being called every frame. Getting near…</added>
[This message has been edited by FermatSpiral (edited 02-17-2003).]