Pouvons-nous considérer un requestAnimFrame comme un « rendement » sur la boucle d'application pour permettre le traitement de la boucle d'événements ?

Question

j'utilise le requestAnimFrame méthode en JavaScript pour mettre à jour mon canevas dans la boucle principale de mon programme :

window.requestAnimFrame = (function(callback) {
  return window.requestAnimationFrame || window.webkitRequestAnimationFrame || window.mozRequestAnimationFrame || window.oRequestAnimationFrame || window.msRequestAnimationFrame ||
    function(callback) {
      window.setTimeout(callback, 1000 / 60);
    };
})();


function animate() {
    requestAnimationFrame( animate );
//var runcount = 100;
//for (var i=0;i<=100;i++) {
    draw();
//    if (runcount === i)
//        alert("Completed program loop");
//    }
}

Ce qui se passait, c'est que mon programme qui n'a mis à jour le canevas qu'après que ma boucle principale ait duré 100 itérations puis arrêté.Après avoir ajouté le méthode ci-dessus dans ma boucle principale, tout à coup je reçois des mises à jour du canevas sur chaque boucle de mon programme.

Le fait que le canevas n'ait pas été mis à jour avant la fin de mon programme m'a fait penser que la mise à jour du canevas s'exécutait dans un thread différent qui n'avait pas la priorité.(Mais nous savons que JavaScript est monothread).

Ma question est - Pouvons-nous considérer un requestAnimFrame comme un « rendement » sur la boucle d'application pour permettre le traitement de la boucle d'événements ? Puis-je toujours supposer que JavaScript est monothread ?

Answer 1

Vous n'êtes pas précis sur la façon dont vous avez effectué votre itération 1000 fois, mais je suppose que vous voulez dire que vous avez itéré en utilisant un for ou while boucle (?Corrige moi si je me trompe..).

Lorsque vous effectuez une boucle for/while, le script sera occupé en boucle jusqu'à ce que cette boucle (ou portée) soit terminée.Comme vous le savez, JS est monothread, il ne peut pas traiter des éléments tels que la file d'attente des événements pendant qu'il le fait - par conséquent, rien ne pourra être mis à jour (incl.DOM) jusqu'à ce que la boucle soit terminée (d'une manière générale, il peut y avoir une implémentation spécifique au navigateur qui autorise les mises à jour du DOM si les mises à jour du DOM sont exécutées sur un thread séparé par exemple, mais c'est une chose distincte de JS).

Maintenant que vous avez implémenté rAF, vous effectuez une seule itération par cadre.Cela signifie que le navigateur a le temps de traiter la file d'attente des événements de manière asynchrone (pas la même chose que multithread) à moins que le code que vous avez traité dans la boucle ait également effectué une boucle occupée pendant un certain temps, ce qui créerait le même scénario que le premier.

Tu aurais pu utiliser setTimeout aussi.Ce que rAF fait différemment de par exemple setTimeout ou setInterval est qu'il s'agit d'une implémentation efficace de bas niveau d'un mécanisme de minuterie capable de se synchroniser avec le moniteur. VBLANC période (effacement vertical auquel la carte vidéo est asservie via une option appelée vsync) - signifiant en clair le taux de rafraîchissement du moniteur (généralement 60 Hz).Cela nous permet de créer une animation plus fluide et c'est pourquoi elle est appelée request*Animation*Frame car c'est à cela qu'elle est principalement destinée.

JS est-il toujours monothread ?Oui, cela ne changera pas (la seule façon de réaliser le multithreading dans JS est d'utiliser Web Workers).

Est-ce que le rAF change quelque chose ?Pas dans ce domaine : c'est une alternative plus précise et plus performante à setTimeout et ça se synchronise différemment mais c'est tout.Il subira les mêmes restrictions qu'avec setTimeout ne pas pouvoir se déclencher si un oscilloscope est occupé (d'où le request* partie du nom qui n'implique aucune garantie) mais lorsqu'il se déclenche, il sera synchronisé avec le taux de rafraîchissement du moniteur.