Je sais que la différence serait actuellement négligeable en raison de la minuterie de navigateur inexacte, mais de la connaissance, ce qui n'a rien d'autre: existe-t-il un navigateur qui soutient seinterval et settimeout, mais nécessite qu'ils soient passés une valeur entière comme retard ?
ou, reformé avec des exemples, est-ce: p> comme navigateur croisé compatible comme ceci? P> setInterval(animate,17);
4 Réponses :
J'imagine que le deuxième paramètre serait évalué comme une expression et aussi longtemps qu'il renvoie un nombre auquel il fonctionnera. Il semble fonctionner en chrome. Assurez-vous simplement de ne pas diviser par zéro!
Ces fonctions attendent des millisecondes. Je doute que vous puissiez vous attendre à une précision supérieure à 10ms et de navigateurs Appliquer des restrictions de minuterie .
Firefox ne dérange pas les valeurs décimales. peut tester dans tout autre navigateur que vous êtes curieux.
Merci pour la réponse. Comme ci-dessus, je ne suis pas préoccupé par un timing précis autant que la dérive (imperceptible bien que cela puisse être).
JavaScript ne fait aucune distinction réelle entre les nombres de points flottants et les entiers et sont les mêmes types de données sous la hotte. Par conséquent, oui, vous pouvez transmettre une valeur fractionnée sans aucun problème réel. C'est parfaitement valide JavaScript. Et même si cela avait besoin d'un entier, il est plus probable que cela arrondit simplement et silencieusement pour vous.
1 et 1.0 est un bit pour un bit identique en mémoire.
0,1 , 1 ou même 4.87 4.87 va probablement tirer probablement très proche du même temps en raison de la faible granularité de la planification de rappel.
Merci, je ne pensais pas à des types de données pour une raison quelconque. Et bon point sur le granulatirie - IIRC, c'est souvent aussi mauvais que 15ms. Mon inquiétude n'est vraiment que pour la dérive (probablement imperceptible) d'un intervalle de longue durée.
La dérive est réelle et c'était un problème que j'ai récemment couru avec l'utilisation de la musique à temps. Et ça craint. C'était ma solution: Alexwayne.tumblr.com/post/13744997785/CarcaseInval ou ignorer La prose et obtenez mon code brut ici: gist.github.com/1D99B3CD81D610AC7351
Le fait que 1 et 1.0 représente la même valeur de numéro dans la langue javascript n'est pas pertinente ici. La question concerne le comportement de la fonction Settimeout . Notez que cette fonction ne fait pas partie de la langue javascript. C'est une fonction de navigateur spécifiée dans la norme HTML. Autant que je puisse dire, si un nombre non naturel est fourni en tant que deuxième argument (comme 1.23 ), le comportement est indéfini, ce qui signifie qu'il appartient aux navigateurs de mettre en œuvre un comportement pour cela. .
Tout vrai. Mais dans la pratique, il l'arrête à un entier ou qu'il l'utilise vraiment comme fractionnel. De toute façon, vous ne savez pas vraiment. Et de toute façon la réponse à est-elle prudente de transmettre seinterval ou de régler un délai fractionnaire? est un "oui c'est bien sans ambiguïté".
Merci pour le code - ce n'est pas exactement pertinent pour ma candidature actuelle, mais pas intéressante néanmoins. Donc, vous avez effectivement trouvé de meilleurs résultats avec les délais d'attente et obtenir à plusieurs reprises des horodatages que des intervalles? De plus, on dirait que vous aviez raison, mais PST a souligné qu'il est effectivement tronqué en dehors de JavaScript. Donc, ce serait une idée (légèrement) meilleure pour simplement écrire le numéro qui sera utilisé.
Je suis à peu près sûr que le délai d'attente et l'intervalle utilisent tous les deux la même planification. Mais utiliser un délai d'attente vous permet de personnaliser combien de temps jusqu'au prochain appel. Cela vous permet de compenser toute dérive de la prochaine itération causée par le rappel exécutant un milliseconde ou deux en retard.
Oui, mais j'avais l'impression que les appels installés étaient programmés à un intervalle défini, peu importe la durée de fonctionnement du code (à moins que cela ne doive plus que l'intervalle). Il semble que vous trouviez que cela ne soit pas le cas? Ou peut-être que votre fonction a-t-elle couru plus longtemps que votre intervalle?
Drift in setInterval était réel pour moi. Il semble être mis en œuvre de manière à ce que setingerval (fn, 1000) signifie: planifier un rappel sur fn dans 1000ms. Quand ce rappel est déclenché, planifiez un autre rappel sur une autre 1 000 ms à partir de l'heure actuelle. Donc, si le premier rappel traverse réellement 1 ms ou 2 ms de retard (ce qui arrive beaucoup), vous venez de perdre 2 ms de manière permanente. Ma mise en œuvre détecte cette dérive et planifie le prochain rappel à 1000ms - 2ms , ce qui constitue le fait que le rappel a couru un peu tard.
Oh, Wow, je n'ai pas réalisé que - je pensais que tous les rappels étaient programmés par rapport au temps d'invocation. Merci pour l'explication.
Il est parfaitement sûr.
(comme le souligne Robg, je n'ai aucune référence aux règles du pont DOM / JS eux-mêmes et il demande la prudence. FWIW, je crois - mais n'a aucune référence à l'état de conclusivité - que Ceci est parce que le DOM L'interface n'accepte que les entiers pour le délai dans Cependant, les exemples généreront effectivement des résultats légèrement différents (bien qu'il ne soit pas notifable): -)
Ceci est parce que, codage heureux.
* TOINTEGER < / code> est partie de l'interface pont. Voici un Jsfiddle montrant le délai d'attente Être transmis comme une ficelle, un flotteur et une intégrale (même type que flottant dans JS) qui fonctionne bien dans FF8 et IE9. Rétroaction Bienvenue.)
SetTimeOUT / SETITINTERVAL - YUP, ceux-ci sont définis dans le DOM, pas dans la carte ECMAScript. La valeur de retard est correctement convertie en une valeur intégrale d'abord (et dans cet aspect, la fonction [JS-interne] TOINTEGER est invoquée qui effectue une troncature *).
50/3 ( 16.66andsomemore -> 16 ) et 17 Spécifiez différents délais d'attente .
TOINTEGER est défini comme signe (numéro) * plancher (ABS (numéro)) , à l'exclusion des cas spéciaux. Voir la section 9.4 de la spécification de la 5ème édition Ecmascript.
OK, cette spécification décrit donc la mise en œuvre C (ou autre chose et non JavaScript), non? La troncature survient-elle en dehors de l'environnement JavaScript?
@ skier88 techniquement, la mise en œuvre du DOM n'est pas avoir dans C - bien que je soupçonne que ce soit dans la plupart des cas - mais il restreint la valeur à une "longue" intégrale. Il existe une partie [N inaccessible à l'utilisateur] du moteur JS qui sait comment "parler à la DOM" qui fait les conversions vers / depuis le DOM. Le lien posté couvre simplement les contrats interface . La fonction TOINTEGER est une fonction interne définie dans ECMAScript, et je crois - mais je me trompe - que cela (ou un équivalent) est utilisé dans la conversion intégrale.
Ouais, je sais que la langue peut varier, cela m'aide juste à penser à un exemple de langage de programmation pour visualiser quel code de niveau est exécuté à. Merci pour la réponse - j'ai probablement dû télécharger la spécification il y a longtemps.
Je ne l'appellerais pas "parfaitement sûr". La spécification HTML5 (qui n'est pas une norme) dit "Timeout optionnel de longue date", alors donnez-lui un entier et ne dépend pas de la correction d'erreur.
@Robg Je pense toujours que c'est parfaitement sûr - par exemple. transmettez-le une chaîne et il ne saura pas, mais sera converti par TOINTEGER Toutefois, comme je ne peux pas trouver une référence quant à la réelle Pont DOM / JS, je ne peux pas réfuter ça ... Voici un Jsfiddle
@ PST-Nul doute qu'il fonctionne bien dans tous les navigateurs que vous avez testés. Je me souviens qu'il y a quelque temps, définir une propriété de style qui souhaitait un entier utilisant un flotteur - la plupart des navigateurs viennent de tronquer le flotteur, d'autres ont jeté une erreur. J'ai donc appris qu'il est bien préférable de réparer d'abord d'éventuelles erreurs et de ne pas compter sur les aléas de la correction des erreurs de navigateur le faisant pour moi.
La façon dont il est défini, le deuxième argument est le "nombre de millisecondes". Maintenant, si ce nombre devrait être naturel n'est pas défini ...
@ Šimevidas C'est parfaitement défini. Voir la spécification DOM ;-)