Discussion :

[jlg_47]

Bonjour,

J'utilise un timer dans une winforms et je remarque qu'il n'est pas pr�cis .. Il est trop lent d'environ 10% ..

Voici mon code :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
private: System::Void Form1_Load(System::Object^  sender, System::EventArgs^  e) {
        time = 0.;
        timer1-> Interval = 100;   // timer à 100 ms
        timer1->Enabled = true;
}
private: System::Void timer1_Tick(System::Object^  sender, System::EventArgs^  e) {
	time = time +0.1;
        TimeLabel->Text = time.ToString();
			 }

Au bout de 60 secondes, mon timer en a compt� 55 environ ...

Quelqu'un a t-il d�j� remarqu� cela?

Ou y a t-il une erreur dans ma mani�re d'utiliser le timer?

Bonne journ�e � tous.

[bacelar]

Les Windows (autre que WinCE) n'ont jamais �t� des OS temps r�els.

Des Timers, il y en a, au bas mot, une demi-douzaine de type, chacun avec des avantages et des inconv�nients.

Mais aucun ne pourra vous permettre d'�viter une d�rive.

Il y a quelques techniques pour limiter cette d�rive mais vous devrez toujours la compenser.

Quel est votre besoin ?
Car le type de timer doit �tre adapt� � votre besoin.

[jlg_47]

Merci pour cette r�ponse rapide.

Je me doutais un peu qu'il y avait une histoire de temps de r�el, d'interruption et je ne sais quoi encore ...

En fait dans mon cas ce n'est pas tr�s grave, je simule un processus et j'essaie simplement de cadencer les calculs pour que le processus avance � peu pr�s � vitesse r�elle ...

Donc a chaque tick du timer (100 ms), je lance une grosse fonction qui fait une s�rie de calculs correspondant � 100 ms du processus ...

J'ai donc remarqu� qu'il faut que je mette le timer � 90 ms pour avancer de fa�on presque exacte.

Par contre je me pose une question importante :

Que se passe t-il si les calculs durent plus longtemps que l'intervalle du timer?

Est ce que je perds un tick, ce qui serait le moindre mal
ou est ce que ma fonction est amput�e pour red�marrer au d�but, ce qui serait une catastrophe.

Apparemment d'apr�s mes essais, ce serait la premi�re hypoth�se qui serait la bonne.

Je tenterais bien de me lancer dans le multithreading, mais j'ai peur de ne pas y arriver et de ne pas avoir le temps car j'ai une �ch�ance � tenir.

[bacelar]

Est ce que je perds un tick, ce qui serait le moindre mal
ou est ce que ma fonction est amput�e pour red�marrer au d�but, ce qui serait une catastrophe.

Cela est fonction du type de timer utilis�, mais les timer de "haut niveau" que le commun des d�veloppeurs utilise ont 3 modes d'ex�cutions:
- soit buff�ris�, l'�v�nement est stock� dans une file jusqu'� "consommation".
- soit drapeau, le fait qu'un timer se d�clenche correspond � un drapeau qui est r�guli�rement v�rifi�, donc avec pertes d'�v�nements en cas de retard.
- soit ex�cution de la proc�dure de traitement de mani�re concurrente des autres traitements d'�v�nements, donc multi-threading ou approche similaire, avec les risques d'acc�s aux donn�es partag�s inh�rents � ce type d'approche.

Mais, au vu de votre description, je ne m'emb�terais pas.

Soit une approche compl�tement dissoci�e (pas de contraintes temps-r�el):
- avec un processus de calcul qui n'a pas besoin d'�tre temps r�el.
- un processus qui n'aurait pour fonction que de visualiser le r�sultat du calcul.

Soit une approche avec un seul processus mais 2 threads, si la simulation doit r�agir � des actions de l'utilisateur.
- un thread de calcul qui ne g�re pas d'IHM mais avec un niveau de priorit� peu important
- un thread d'IHM qui lira le r�sultat de calcul et r�agira aux actions de l'utilisateur avec un niveau de priorit� plus important mais qui fait tr�s peu de chose, puisqu'il attend les actions de l'utilisateur.
Il faudra juste bloquer temporairement le thread de simulation s'il prend trop d'avance sur la timeline de l'IHM.