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.