Plusieurs requestAnimationFrame performance

Si je suis en train de faire de multiples animations, est-il acceptable de performance pour ajouter plusieurs requestAnimationFrame rappels? F. ex:

function anim1() {
    //animate element 1
}

function anim2() {
    //animate element 2
}

function anim3() {
    //animate element 3
}

requestAnimationFrame(anim1);
requestAnimationFrame(anim2);
requestAnimationFrame(anim3);

Ou est-il prouvé pire qu'à l'aide d'un simple rappel:

(function anim() {
    requestAnimationFrame(anim);
    anim1();
    anim2();
    anim3();
}());

Je demande parce que je ne sais pas vraiment ce qui se passe derrière les coulisses, est requestAnimationFrame files d'attente des rappels lorsque vous l'appeler plusieurs fois?

InformationsquelleAutor David Hellsing | 2013-06-14

7

Vous devriez être en utilisant seulement un requestAnimationFrame appel que les appels à requestAnimationFrame faire de la pile. Le seul rappel de la version est donc plus performant.
- Êtes-vous sûr de cela? Selon w3.org/TR/animation-timing/#FrameRequestCallback, les rappels sont stockés dans une liste et exécutés dans l'ordre. Pourquoi un rappel unique avec 3 animations être plus efficace que les 3 rappels avec 1 animation?
- Pour le simple fait que vous faire 2 appels de fonction moins.
- est droit, moins d'appels de fonction sera égal à moins de charge de la pile. Cependant, je peux voir l'application en particulier pour les animations de courte durée que le feu rarement à vivre en dehors de la boucle principale pour le codage de la simplicité. En outre, la suppression d'une ramification de l'intérieur d'une "hot" en boucle dans ta boucle principale peut réduire tout compilateur JIT raclée en raison de la liaison, la dissociation, la création d'objets natifs etc...
- la performance réelle de comparaison: jsperf.com/single-raf-draw-calls-vs-multiple-raf-draw-calls c'est clairement une 3x performances, mais je serais curieux de savoir quel genre de perceptible goulot d'étranglement des performances qui en fait se traduit par
- comme le remarque importante, afin de mieux comprendre la "derrière la scène", j'ai découvert que les multiples invocation avec la même fonction, rendre l'animation plus rapide.
InformationsquelleAutor Erik Schierboom

Quelqu'un étalonnés cette. Parlons-en...

https://jsperf.com/single-raf-draw-calls-vs-multiple-raf-draw-calls

J'ai regardé la comparaison des performances (vous devriez aussi). Vous êtes les bienvenus pour en désaccord. Ce sont des primitives de dessin sur une toile élément.

        function timeStamp() {
          return window.performance && window.performance.now ? window.performance.now() : new Date().getTime();
        }

        function frame() {
            drawCircle();
            drawLines();
            drawRect();
        }

        function render() {
            if (timeStamp() >= (time || timeStamp())) {
                time = timeStamp() + delayDraw;
                frame();
            } 
            requestAnimationFrame(render);
        }

        function render1() {
            if (timeStamp() >= (time || timeStamp())) {
                time = timeStamp() + delayDraw;
                drawCircle();
            } 
            requestAnimationFrame(render1);
        }

        function render2() {
            if (timeStamp() >= (time || timeStamp())) {
                time = timeStamp() + delayDraw;
                drawRect();
            } 
            requestAnimationFrame(render2);
        }

        function render3() {
            if (timeStamp() >= (time || timeStamp())) {
                time = timeStamp() + delayDraw;
                drawLines();
            } 
            requestAnimationFrame(render3);
        }

Je pense que ce code est vraiment l'analyse comparative de 7 appels à timestamp() vs 2 appels à timestamp(). Regardez la différence entre Chrome 46 et 47.

Chrome 46: 12k/sec (un appel) vs 12k/sec (3 appels)
Chrome 47: 270k/sec (un appel) vs 810k/sec (3 appels)

Je pense que c'est tellement bien optimisé qu'il ne fait pas de différence. C'est juste de mesure de bruit à ce point.

Mon résumé est ce n'a pas besoin d'être optimisé pour mon application.

Si vous êtes inquiet au sujet de la performance de regarder la différence entre Chrome 59 de 1,8 m (ops/sec) vs Chrome 71 (506k ops/sec).

InformationsquelleAutor Michael Cole

-1

La requestAnimationFrame se lie à un appel de fonction et renvoie le frameID. Demander plusieurs images n'est PAS la même, comme l'ajout de plusieurs écouteurs d'événement pour un événement chaque de vos fonctions est appelé dans un autre cadre.
Donc, si vous en continu (chaque fonction se rappelle elle-même de manière récursive) demande de plusieurs images, vous êtes de perdre l'avantage que toutes les mises à jour sont rendus dans une image. Donc, même si il y a un haut taux de rafraîchissement animations peuvent ne pas sembler lisse.

Mais: vous ne pouvez utiliser cancelAnimationFrame(frameID) pour toutes les méthodes et mai besoin d'un peu plus de code pour annuler unique animations
- Ce n'est pas correct, et il peut être un peu difficile à suivre, donc, je comprends comment vous avez atteint cette hypothèse. Toute demande enregistrée avant l'exécution de la prochaine repeindre est ajouté à l'image; il n'y a pas de limite sur le nombre de demandes peuvent être inclus dans chaque image. Le handle retourné par requestAnimationFrame est un IDENTIFIANT de la requête unique à cette demande, et non pas un cadre ID unique pour le cadre. Identifier le cadre unique une demande est en attente pour vous d'utiliser le DOMHighResTimeStamp passé à la fonction que vous avez demandé à être animé. Vous pouvez en lire plus sur MDN.
InformationsquelleAutor Wolfgang

Vous devez vous connecter pour publier un commentaire.