Une boucle infinie "controlable"

Bonjour,

Toujours dans mes petites explorations, je cherche aujourd'hui à créer une boucle infinie et très rapide en Javascript qui a la particularité de ne pas planter (freeze) le navigateur. Exit donc les boucles while & co et bonjour setInterval / setTimeout.

Sauf que le temps minimum entre 2 appels de setInterval (setTimeout) à l'air d'être fixé à 15/16ms. J'imagine qu'il y a une raison, je ne la connais pas... Mais j'aimerais bien la connaitre car ça pourrait être une option intéressante s'il était possible de passer en dessous de cette barre.

Pour faire simple, je vise les 1 ou 2ms par itération,
et suis ouvert à toute proposition.

Merci.

mmm,

Alors il semble que la résolution des timer (ticks) dépendent des OS.
D'après ce que j'ai pu lire, 16ms correspond à windows 2k+ sur un processeur multicore / ht. Etant donné que je suis sur un core 2 duo et sur windows 2000, ça semble aller dans ce sens.

Ce site m'a permi de constater que macOSX tiger avait une resolution de 2ms sur safari 3,
Et aussi que windows 98 sur un singlecore tournait aux alentours de 56ms.

Bref les setInterval / setTimeout ne semblent pas se prêter à une utilisation massive et rapide, et surtout multiplateforme...

Va falloir trouver autre chose.

Ze Nenex a écrit :
mmm,

Alors il semble que la résolution des timer (ticks) dépendent des OS.
D'après ce que j'ai pu lire, 16ms correspond à windows 2k+ sur un processeur multicore / ht. Etant donné que je suis sur un core 2 duo et sur windows 2000, ça semble aller dans ce sens.

Ce site m'a permi de constater que macOSX tiger avait une resolution de 2ms sur safari 3,
Et aussi que windows 98 sur un singlecore tournait aux alentours de 56ms.

Bref les setInterval / setTimeout ne semblent pas se prêter à une utilisation massive et rapide, et surtout multiplateforme...

Va falloir trouver autre chose.

C'est surtout le JS qui ne se prête pas à une utilisation massive et rapide

Javascript étant interpreté par un navigateur, ce temps minimum dépendra donc de la façon dont sont appelés les setTimeout/setInterval, du code executé entre deux, de la capacité du navigateur à interpreter ce code, des ressources de la machine, du nombre de page que le navigateur gère en même temps...

Autrement dit c'est incontrolable.

Sur certaines executions de code, il y a parfois un facteur dix ou quinze entre IE6 et Safari 3, qui est pour l'instant le plus rapide question javascript... pour l'instant car la dernière beta de FF3 semble déjà le surpasser.

Quid d'une boucle type while(true) que l'on retrouve souvent dans les jeux monothread ?
Ou comment contrôler le temps ? i.e créer une boucle type framerate: prendre 2 mesures de temps entre 2 itérations, en cas de dépassement de ration (genre 60 fps = 1 image toutes les ~16ms) on fait une sortie.

Le tout en javascript bien sur...
Ce n'est pas que ça me dépasse, mais je vois mal comment faire.

Hello,

Gatsu35 a bien résumé le sujet, je pense.

S'il s'agit de faire des animations élaborées et très réactives, DHTML n'est pas adapté. Il faut se tourner vers les technos de type applet (Java, Flash, ...).

Julien Royer a écrit :
Il faut se tourner vers les technos de type applet (Java, Flash, ...).

Ouep. C'était la dernière chose que je souhaitais. Mais il va falloir se faire une raison car je ne vois pas de solution.

Quoiqu'en AS ça peut-être marrant aussi,
surtout qu'il y a la classe ExternalInterface maintenant...