How can I get a 30 or 60 frame rate when using QGLWidget? QTimer is not acurate

[ricardo]

I don't see where threads would help in your situation... If you want, you may constantly call updateGL() on your widget and you will get maximum possible framerate. But the problem is generally in your system - XP should handle resolutions larger than 55ms fine. The limitation of 98 comes from the design of the system which was obviously changed in later Windows systems. How did you test that your XP also has the 55ms limitation? Did you try the same program on different systems?

Thanks for reply.

I did a test for you.

Using QTimer with 20 ms and a QTime to know when my app started:

m_timer=new QTimer(this);
m_timer->setInterval(20);
connect(m_timer, SIGNAL(timeout()), this, SLOT(TimerFired()));

void CEditor::TimerFired() {
qDebug() << "t=" << m_time.elapsed();
}

I got these results, which obviusly are not expected (it should be 9578, 9598...)
t= 9578
t= 9610
t= 9641
t= 9672
t= 9703
t= 9735
t= 9766
t= 9797
t= 9828
t= 9860
t= 9891
t= 9922
t= 9953
t= 9985
t= 10016
t= 10047
t= 10078
t= 10110
t= 10141
t= 10172
t= 10203
t= 10235

Any idea?
I have a QuadCore 2.4 GHz and an ATI HD3870, so I don't thinks is because my computer.
Do you all know what going on is? Note this time I am not redrawing and updating my game on TimerFired, so it is even more strange.
Maybe it is because I'm using DEBUG mode, I don't know.

Thanks a lot for your time.

[franz]

What you're running into is a limitation of the (type of) operating system. OSes made for people aren't too strict on timing because there is no need for it.

Also remember two things:

1. Debug mode generally makes your app slower
2. Outputting stuff to console makes your app slower

[ricardo]

What you're running into is a limitation of the (type of) operating system. OSes made for people aren't too strict on timing because there is no need for it.

Also remember two things:

1. Debug mode generally makes your app slower
2. Outputting stuff to console makes your app slower

Thanks for reply.

I did that, relese mode and not writing anything on console. I wrote this test code:

void CEditor::TimerFired() {
	static int rendered_frames=0;
	// draw here whatever
	m_current_level->Update(0);
	m_gl_drawer->updateGL();
	rendered_frames++;
 
	// after 10 seconds
	int total_time=10000;
	if (m_time.elapsed()>total_time) {
		float fps=rendered_frames/(0.001*total_time);
		QString m=QString("FPS: %1. rendered frames: %2. Timer interval (ms): %3. Total time (ms): %4").arg(fps).arg(rendered_frames).arg(SIMULATION_UPDATE_INTERVAL_IN_MS).arg(total_time);
		QMessageBox::warning(this, "Warning", m);
		m_timer->stop();
	}
}

void CEditor::TimerFired() {
	static int rendered_frames=0;
	// draw here whatever
	m_current_level->Update(0);
	m_gl_drawer->updateGL();
	rendered_frames++;

	// after 10 seconds
	int total_time=10000;
	if (m_time.elapsed()>total_time) {
		float fps=rendered_frames/(0.001*total_time);
		QString m=QString("FPS: %1. rendered frames: %2. Timer interval (ms): %3. Total time (ms): %4").arg(fps).arg(rendered_frames).arg(SIMULATION_UPDATE_INTERVAL_IN_MS).arg(total_time);
		QMessageBox::warning(this, "Warning", m);
		m_timer->stop();
	}
}

To copy to clipboard, switch view to plain text mode 

That code will simulate my game for just 10 seconds. 20 ms interval (SIMULATION_UPDATE_INTERVAL_IN_MS) should be 50 frames per sencod. As you can see in this picture, something is wrong.



So, what do you recommend me? Does anyone know why this happens?

Thanks a lot.

[ricardo]

Any idea? I really have no idea why I cann`t get enough FPS.
Thanks.

[hayati]

Off course, Qt signal and slot mechanism is also applied to qtimer's timeout signal.
So you're limited to qapplication's event loop to take care this signal in time. No signal must be handled in time off course.
I experienced 2000 threads and believe me that after a few seconds i hardly get any signals, moreover i had never get timeout signal!
so if you want to make it more accurate, use another thread
and don't use ALARM signal as it's system wide. use "nanosleep" or "select" and give timeout parameter as you wish.

i mean, don't use qtimer if you're doing such kind of processing. Call critical functions with system calls(whatever applies to windows). qtimer is bound to event queue which is not accurate.

so i changed my 2000 threaded code to "select" version then it's running flawlessly now.

Windows system may give you built-in easy to use timer but functions that i mentioned before are for Linux.

And off course these accuracy brings complexity to your application.

[wysota]

This is all wrong. The problem is not the limitation of timers, the problem is that rendering takes time as well. If you set a timeout of a timer to 100ms, then after 1 second you might get from 0 to 10 timeouts (inclusive) and that's perfectly normal. Instead of having a static timeout, one should save the time of last timeout and after the rendering of the frame is done, correct the timeout for next frame to compensate for system being more or less busy.

void MyClass::renderFrame(){
  QTime now;
  now.start();
  renderMe();
  QTimer::singleShot(20-now.elapsed(), this, SLOT(renderFrame())); //should get around 50 FPS
}

void MyClass::renderFrame(){
  QTime now;
  now.start();
  renderMe();
  QTimer::singleShot(20-now.elapsed(), this, SLOT(renderFrame())); //should get around 50 FPS
}

To copy to clipboard, switch view to plain text mode 

This should get more accurate timing (although there is still place for improvement which is left as the task to the reader).

[hayati]

Unfortunately this is not true!
If system is busy in doing someting you may never get timeout calls at all.
and off course painting is a long operation but what is opengl is for.

i mean there is an extra latency for qeventloop which is explained by trolltech's.


may be this thread is useful for explaining latency.

link is here:

http://www.archivum.info/qt-interest...L_:_QEventLoop

and this link:

http://www.archivum.info/qt-interest...tes_for_OpenGL

thanks.

[wysota]

If system is busy in doing someting you may never get timeout calls at all.

That's exactly what I'm saying. After 10 times the timeout value you may get from 0 to 10 timeouts depending on what is happening in the system.

and off course painting is a long operation but what is opengl is for.

You mean you have only fully OpenGL applications in your system?

The latency of the loop is obvious (it does "something", so it introduces a delay), but it is nothing compared to latency of the whole system. Try running a few "while(1);" applications and at the same time run a simple application with a timer triggering at 10Hz, regardless if you are using OpenGL or not.

Bottom line is - without a real time operating system you may never trust any timers - it is a tool, not a panaceum.

[hayati]

i think second link of my previous post also discusses same issue. That's why i gave these links from trolls' side.

At the end both side agrees on QTimer is not well suited for that kind of update triggering.

Thanks

[wysota]

At the end both side agrees on QTimer is not well suited for that kind of update triggering.

It's fine, it just needs to be used properly. Using sleep() or any of its variants wouldn't change a thing.

[ricardo]

@hayati: Are you telling I should use a thread? USually, common games only use a thread in their main loop.
Useful links, Now I reading them, thanks.
If I use a thread to update and render my game, does this create any multithreaded problem? I mean, shared variables... (I'm not an expert in MT apps)
If I use a thread, can I have issues with keyboard and mouse events?



@wysota: Evidently updating and rendering takes time, but I read this form docs: (constant intervals)
"The QTimer class provides a high-level programming interface for timers. To use it, create a QTimer, connect its timeout() signal to the appropriate slots, and call start(). From then on it will emit the timeout() signal at constant intervals."
Did you try your method? are you sure it works? I will try it tomorrow.

"without a real time operating system you may never trust any timers - it is a tool, not a panaceum."
I don't think I need that accuracy, just about 45 and 55 FPS would be nice to create a good simulation.




What do you all thinks about http://www.libqglviewer.com/?
I didn't use it, but reading some docs I read
http://www.libqglviewer.com/features.htm
"Possible animation of the scene at a given frame rate"

Does anyone use that library?


Thanks a lot for help.

[wysota]

@wysota: Evidently updating and rendering takes time, but I read this form docs: (constant intervals)
"The QTimer class provides a high-level programming interface for timers. To use it, create a QTimer, connect its timeout() signal to the appropriate slots, and call start(). From then on it will emit the timeout() signal at constant intervals."

"Constant intervals" is an approximation. Timers are not guaranteed to fire under stress on non-realtime operating systems. There's really nothing to discuss.

Did you try your method? are you sure it works?

Why shouldn't it work? It's an adaptive timer which makes the frame rate more stable than using a non-adaptive timer.

"without a real time operating system you may never trust any timers - it is a tool, not a panaceum."
I don't think I need that accuracy, just about 45 and 55 FPS would be nice to create a good simulation.

You can't get even that. There is no guarantee - the kernel might preempty your process at any time for any amount of time (like 10 minutes, if it felt like doing so - of course usually it doesn't). There is just no way you can get a timeout during that period.

You have to stick with "most of the time in normal conditions you will get 20-60ms accuracy" (consider the difference between resolution and stability of the rate). But you can compensate for "lost frames" by using adaptive timers (and even skipping rendering frames to catch up) - in reality redrawing framerate is not important at all (as long as it's over 16fps so that your eye can perceive it as animation - the brain will interpolate properly) - it is important that the logic is updated fluently (to prevent the game from "lagging behind") which is completely enough in your case. You can even adapt the complexity of scene rendering to compensate lags. Remember that computer graphics is mostly about cheating.

And to stress again - using another thread will only make things worse as the system will have to context-switch between threads thus losing more time (for a moment ignoring the fact you can't paint from worker threads in Qt) doing completely nothing from your application's point of view. You can use sleep/msleep/nanosleep in the main thread just as well but it won't change the fact that these functions only guarantee that you will not be woken before the given time elapses, nothing more.