Discussion :

[nuKs]

Bonjour à tous.
Je ne comprend pas pourquoi mon timer fonctionne très lentement.
Après 30 secondes j'arrive à un output +- égal à 3.…
boost.timer est donc 10x trop lent, sachant que selon les spec, elapsed() renvoi des secondes.
Pour info j'utilise boost 1.44 et je suis sous mac os 10.6.5. J'utilise GCC 4.0 et je compile pour le SDK Mac OS 10.5 en 32bit universal.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
	boost::timer t;
	while(1)
		LOGInfo << t.elapsed();

Quelqu'un aurait-il une idée du problème ?
Merci d'avance

[vikki]

Étrange, chez moi ce simple code fonctionne très bien (sous Win):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
boost::timer t;
	while(1)
		std::cout << t.elapsed()<<std::endl;

Ce ne serait pas plutôt ton système de log qui pose problème? genre retard à l'affichage?

[Emmanuel Deloget]

C'est quoi LOGInfo ?

[nuKs]

LOGInfo est mon système de log.
Oui en effet lorsque j'effectue l'affichage 1x sur 100 000 ça fonctionne à une vitesse relativement normale. C'est ce que je craignais.

En réalité mon code utilise un timer boost qui est comparé à chaque frame avec une map contenant comme clé un double et comme valeur une fonction callback. Après 3secondes, l'écran est sensé changé. Il en faut malheureusement bien plus, et sans output j'ai donc aussi un retard assez important.
J'en conclus que dans mon cas, ce n'est pas l'affichage qui est en décalage avec le temps mais bien le timer.

J'ai essayé de limité ma boucle d'une telle manière :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
if(_secSinceLastFrame.elapsed() < 1.0f/25) // Limit fps to 25
	return true;
LOGInfo << " " << _secSinceStart.elapsed();
…

et c'est toujours très imprécis. (Pour info LOGInfo n'est pas beaucoup plus lent que std::cout).

Même en utilisant nanosleep le résultat est toujours aussi décevant. C'est comme si boost::timer utilisait un temps relatif (à chaque appel, on augmente le temps de (timestamp actuel - timestamp au dernier appel) ) au lieu d'un temps absolu (temps = timestamp actuel - timestamp au démarrage). Quelqu'un peut-il me confirmer cela ? Dans ce cas présent, connaîtriez vous une bonne alternative portable à boost::timer ?

Merci d'avoir répondu

[Emmanuel Deloget]

Le utilisé par boost::timer n'est pas relatif. Chaque appel de elapsed() force un appel à std::clock(). Je ne vois pas comment ça ne pourrait pas fonctionner correctement, d'où ma question. Je pense qu'il est possible qu'un problème se soit glissé dans ton code pour LOGInfo (je me doutais bien qu'avec un nom comme ça, il y avait des chances que ça soit un système de log )

Est-ce que tu pourrais nous faire profiter de ce code, histoire de vérifier s'il n'y a pas un problème ?

[nuKs]

Woups. Désolé pour ma réponse un peu stupide
Pour en revenir au sujet, je me suis mal exprimé. La lenteur n'est pas due au LOGInfo. J'ai essayé la même chose avec std::cout.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
boost::timer t;
	while(1)
		std::cout << t.elapsed()<<std::endl;

Ca affiche un résultat beaucoup trop lent. Ces instructions sont bien au début du main (donc ce bout de code est testé indépendamment du reste).
Lorsque je n'affiche le résultat qu'une fois sur 100 000 000, le résultat est plus probant.

La réponse de Vikki me porte à penser que c'est peut-être mon OS qui est en cause étant donné que ça semble fonctionner à une vitesse normale chez lui.

Je pense malheureusement que ce n'est pas l'affichage qui est décalé par rapport au programme mais bien le timer qui est en retard sur la réalité. J'en arrive à cette conclusion car dans mon code original, il n'y a aucun Log dans la boucle elle même, mais les actions devant se réaliser après un certain temps se réalisent bien trop tard.

Pour le code, voici une partie de mon "FrameEngine"
http://pastebin.com/fAzLiFd7
Je doute que ça soit de grande aide. Si vous souhaitez tout de même le code du Logger je vous le fournirai directement.