01-08-2014, 03:01 PM
Fais gaffe à tes URLs, rédige-les proprement sinon les parenthèses et ponctuations viennent y mettre le bazar (insère une espace entre l'URL et la ponctuation qui la suit).
La spécif' du W3C me semble laisser de grandes largesses au navigateur pour définir la fréquence d'appel aux callbacks. De toute façon, si la page est masquée, elle n'est pas redessinée (comme dit dans ton message), donc se baser sur "requestAnimationFrame() est régulier" mènera à des bricolages et des codes truffés de bouts de scotch.
Donc, c'est normal que le temps entre deux appels aux callbacks de requestAnimationFrame() soit assez inconsistant.
"il n'y a pas de perte de frame". D'après le document "for example, using setTimeout with a 10ms period results in every third callback not being painted", donc la callback est toujours appelée dans les deux cas (setTimeout et requestAnimationFrame), mais rien ne garantit que ce que la callback du setTimeout dessine sera affiché, alors qu'avec requestAnimationFrame() ce que la callback exécute sera forcément affiché.
Pour ton histoire de "frame perdu" dans ton test, le soucis vient de la concurrence des incrémentations. Si "console.log(counter);" est passé dans frame2() au lieu de frame1(), les résultats diffèrent, la cause étant que les deux méthodes se déroulent "grosso modo" en parallèle, et que leurs instructions peuvent s'exécuter dans n'importe quel ordre entre les deux fonctions (note: en tous cas, c'est l'impression qu'elles me donnent mais je ne connais pas assez la spécif' JVS pour l'affirmer complètement).
Le seul intérêt de requestAnimationFrame() est de dire: "Voici la fonction à appeler avant de dessiner la page à l'écran; ce que cette fonction dicte doit être affiché".
On ne peut s'appuyer sur aucune notion de temps, uniquement sur les frames qui sont dessinées à l'écran.
Pour l'utiliser correctement, il faut donc découpler le calcul de l'affichage (le requestAnimationFrame et sa callback) du calcul du monde virtuel (quelle sprite de l'animation afficher, quels calculs physiques à effectuer, etc). C'est pour cela que les frameworks JVS sont très utiles si tu te lances là-dedans, puisque cela revient à re-coder un moteur de jeu complet (c'est aussi la raison pour laquelle j'évite le JVS...).
La spécif' du W3C me semble laisser de grandes largesses au navigateur pour définir la fréquence d'appel aux callbacks. De toute façon, si la page est masquée, elle n'est pas redessinée (comme dit dans ton message), donc se baser sur "requestAnimationFrame() est régulier" mènera à des bricolages et des codes truffés de bouts de scotch.
Donc, c'est normal que le temps entre deux appels aux callbacks de requestAnimationFrame() soit assez inconsistant.
"il n'y a pas de perte de frame". D'après le document "for example, using setTimeout with a 10ms period results in every third callback not being painted", donc la callback est toujours appelée dans les deux cas (setTimeout et requestAnimationFrame), mais rien ne garantit que ce que la callback du setTimeout dessine sera affiché, alors qu'avec requestAnimationFrame() ce que la callback exécute sera forcément affiché.
Pour ton histoire de "frame perdu" dans ton test, le soucis vient de la concurrence des incrémentations. Si "console.log(counter);" est passé dans frame2() au lieu de frame1(), les résultats diffèrent, la cause étant que les deux méthodes se déroulent "grosso modo" en parallèle, et que leurs instructions peuvent s'exécuter dans n'importe quel ordre entre les deux fonctions (note: en tous cas, c'est l'impression qu'elles me donnent mais je ne connais pas assez la spécif' JVS pour l'affirmer complètement).
Le seul intérêt de requestAnimationFrame() est de dire: "Voici la fonction à appeler avant de dessiner la page à l'écran; ce que cette fonction dicte doit être affiché".
On ne peut s'appuyer sur aucune notion de temps, uniquement sur les frames qui sont dessinées à l'écran.
Pour l'utiliser correctement, il faut donc découpler le calcul de l'affichage (le requestAnimationFrame et sa callback) du calcul du monde virtuel (quelle sprite de l'animation afficher, quels calculs physiques à effectuer, etc). C'est pour cela que les frameworks JVS sont très utiles si tu te lances là-dedans, puisque cela revient à re-coder un moteur de jeu complet (c'est aussi la raison pour laquelle j'évite le JVS...).