Discussion :

[cs_ntd]

Bonjour à tous,

Dans une application, j'ai besoin qu'un évènement se déclenche à une fréquence bien précise, et c'est pourquoi j'utilise la classe Timer.
Or je rencontre un souci de précision : lorsque par exemple ma fréquence est de 1000/minutes, l'évènement ne se produit en réalité que 958 fois par minutes...
Est-ce la précision du timer qui n'est pas suffisante? Ou bien cela vient-il de mes calculs pour calculer la période à partir d'une fréquence donnée?

Voila comment je procède :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
public float f;
public float periode;
public float msDuration;
 
f = (int) numericUpDown1.Value;
f = f / 60F; //la fréquence est en évènements/minute, je la passe en évènements/seconde
periode = 1 / f;
msDuration = periode * 1000F; //passage de la période en millisecondes
timer1.Interval = (int) msDuration;

Il y a en effet perte de précision quand j'attribue sa valeur a timer1.Interval du fait de la reconversion en int, mais comment faire autrement ???

Je vient de faire un essai avec 6000 évènements/minutes : le nombre d'évènements réalisés en réalité sont de 3800 ! Alors que normalement, 6000/60 donne 100, 1/100 donne 0,01 et 0,01 * 1000 donne 10, ce qui en théorie n'entraîne pas de perte au niveau de la reconversion en int...

Avec 600, soit un évènement tous les 100 millisecondes on obtient 548 éxécutions...

Au passage, je précise que mon évènement n'est pas extrèmement important, ce n'est pour l'instant qu'un changement de valeur d'un label...

Merci d'avance à tous ceux qui me répondront...

[tomlev]

si tu utilises le timer de Windows Forms (System.Windows.Forms.Timer), c'est normal
Utilise plutôt System.Timers.Timer ou System.Threading.Timer
Il y a des comparatifs ici :
http://msdn.microsoft.com/en-us/magazine/cc164015.aspx
et là :
http://mark.michaelis.net/Blog/Syste...mersTimer.aspx

[cs_ntd]

Quel intéret d'offrir un timer si il ne marche pas ???

Car en effet c'est bien le timer de Windows Forms que j'utilise... mais je ne trouve pas ça normal pour autant

Enfin merci de tes réponses tomlev, je vais potasser tes compartifs et faire des tests, et je repasserais ici au besoin si sa ne marche toujours pas...

[smyley]

Quel intéret d'offrir un timer si il ne marche pas ???

Et pourquoi devrait-on offrir un timer super précis alors qu'on en a pas besoin ? Chacun des deux timers a son utilité, après ça dépend de ce que l'on veut. Le timer de System.Windows.Forms par exemple garantit que l'évènement Tick sera bien appelé sur le même Thread que la fenêtre sur laquelle il a été construit (je rappel qu'on ne peut pas normalement accéder à l'interface graphique à partir d'un thread autre que celui qui l'a crée) et aussi qu'on ne va pas avoir plusieurs Tick qui s'exécutent en même temps (ce qui pourrai conduire à des effets néfastes). De son coté le timer du System.Threading offre une plus grande précision mais effectue à chaque fois l'appel du callback dans un nouveau thread (donc rien n'interdit qu'on soit plusieurs fois dans le même callback en même temps mais sur des threads séparés et si les objets que l'on utilisent ne sont pas ThreadSafe, c'est le calvaire) ...
voilà ..

[cs_ntd]

Et pourquoi devrait-on offrir un timer super précis alors qu'on en a pas besoin ?

Et en quoi l'utilisation du timer de Windows Form inclus que l'on a pas besoin d'un timer précis?
A moins que les propriétés de ce timer que tu as décrites soient incompatible avec une bonne précision, je ne m'y connais pas assez pour le dire.

Mais ce que je voulais remarquer, c'est que on a un timer qui peut être vraiment inutile : à un évenements toutes les 10 millisecondes théoriquement, j'ai en réalité un évènement toutes les 16 millisecondes, soit à la place de 6000 évènements/minute, 3800/minute...
Là je suis vraiment loin d'exiger un timer "super précis", mais simplement un timer correct je trouve... mais c'est subjectif, tout dépend de ce que tu entends par super précis

[smyley]

Aargh, je m'exprime si mal que ça ?
En court donc :
- Si t'as besoin d'un timer histoire d'arranger des contrôles windows (faire clignoter un bouton ou des choses du genre) : l'utilisateur ne va pas sentir la différence entre 10 ms et 16 ms => System.Windows.Forms.Timer
- Si t'as besoin de te dire que tu veux vraiment plus de précision ou que tu as des intervalles très courtes => System.Threading....Timer et dans ce cas si tu touches à l'interface il faudra faire des this.Invoke(..) pour y accéder.

[cs_ntd]

Aargh, je m'exprime si mal que ça ?

Non non sa va tu t'exprime très bien, moi par contre je suis fatigué desfois

Si t'as besoin d'un timer histoire d'arranger des contrôles windows (faire clignoter un bouton ou des choses du genre) : l'utilisateur ne va pas sentir la différence entre 10 ms et 16 ms => System.Windows.Forms.Timer

Ok sur la forme, on a pas besoin d'un truc précis mais, moi je me demande juste si sa coutait vraiment beaucoup de faire un truc un peu précis tout de même... mais bon c'est vrai qu'on s'en fiche parceque c'est pas fais pour ça

Si t'as besoin de te dire que tu veux vraiment plus de précision ou que tu as des intervalles très courtes => System.Threading....Timer et dans ce cas si tu touches à l'interface il faudra faire des this.Invoke(..) pour y accéder.

Ok aussi, là c'est fait pour la précision... Mais je fait un rêve... un timer qui "garantit que l'évènement Tick sera bien appelé sur le même Thread que la fenêtre sur laquelle il a été construit"... et qui soit précis

Mais baste laissons ceci puisque ce n'est pas prévu, ce n'est pas prévu, et je sais maintenant à quoi m'en tenir pour la précision

[smyley]

Non mais attend, le simple fait que Tick soit toujours sur le même Thread baisse la précision.
* Un Timer avec Tick sur le même thread :
- On attend
- L'intervalle arrive à terme
- On appelle Tick et on ATTEND que Tick soit terminé
- On continue
Sauf que si Tick prend du temps, le timer va être obligé d'attendre vu qu'il n'a pas le droit de faire un autre Tick avant que le premier ne soit terminé

* Pour l'autre timer de Threading
- On attend
- L'intervalle arrive à terme
- On crée un nouveau thread et dessus on appel "Tick"
- On continue pendant que Tick est toujours en cours
Et donc là, on peut très bien avoir plusieurs Tick en même temps emais one ne perd pas de temps à attendre la fin de Tick ...