[JS] requestAnimationFrame

[Argorate]

Bonjour,

après quelques tests, j'aimerais bien avoir plus de précision sur requestAnimationFrame(callback).

Le principe si j'ai bien suivit, c'est qu'avant chaque repaint/frame, le callback est appelé.
On ne peux donc pas aller "plus vite" que le nombre de fois où callback est appelé.
L’interface entre frame est supposé relativement fixe pour un même PC mais diffère d'un PC à l'autre suivant le matériel.
On peut en appeler plusieurs en parallèle au risque de faire décroitre les FPS (http://cssdeck.com/labs/v3r32y1m )

Déjà, j'ai un premier soucis, c'est qu’apparemment le repaint est retarder par le(s) callback (voir exemple: http://jsfiddle.net/nqqfq/18/ ), du coup dire qu'il y a des frames à intervalle régulier est faux, ça dépend de la lenteur d’exécution du code dans le callback.

Ensuite, c'est supposé être mieux qu'un setTimeout(), mais à ce que je vois (http://jsfiddle.net/nqqfq/16/ ) y a autant d'inconstance dans le temps qui sépare deux appels successif.

Apriori, ici http://ie.microsoft.com/testdrive/Graphi...fault.html , ils semblent dire qu'il n'y a pas de perte de frame, mais je vois pas trop de différence (sans doute à cause de mon PC).
En plus si je compte les frames: http://jsfiddle.net/nqqfq/20/ (dans la console), on voit l'inverse de ce qui est annoncé: requestAnimationFrame perd parfois des frames par rapport au setTimeout... C'est à n'y rien comprendre


Enfin, le requestAnimationFrame est lui aussi sensible au changement d'onglet/application et s’arrête/ralenti quand le focus n'est pas sur la page, comme un setTimeout, du coup il n'y a pas non plus d'avantage de ce coté là.

Bref, il doit me manquer un truc, parce que pour l'instant j'ai du mal à voir comment l'utiliser correctement.


Vos avis/retour d'expérience?

[Xenos]

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...).