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

[ricardo]

Hi dudes!

I have a little problem. I'm doing a level editor where level can be created and played in real time. Now I'm using a QTimer to update my objects (position and logic) and render them (using updateGL from QGLWidget) when somebody wants to play a level.

But using a QTimer is not going well.

"Windows 98 has 55 millisecond accuracy; other systems that we have tested can handle 1 millisecond intervals."
http://doc.trolltech.com/4.5/timers.html

It seems Windows XP has the same problem, just a 55 ms accuracy. BTW, I use VS2005, WinXP and Qt 4.5 on a good PC

The problem is that 55 ms means 18 frames per second, which is not as good as I thought. For gaming I will require at least 30 FPS (60 FPS even better)

Do you have any suggestion or idea?

Do you believe I should use threads or consider them? I dont know too much about theads, What cautions should I take to avoid problems with my UI? (I mean, shared variables or that)

Thanks a lot for your help and time.

[wysota]

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?

[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