Possiamo considerare un requestimimFrame un 'rendimento' sul ciclo dell'applicazione per consentire il processo di evento di elaborare?

Question

Sto usando il Metodo requestAnimFrame in JavaScript Rendi il mio aggiornamento su tela all'interno del loop principale del mio programma:

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");
//    }
}

.

Che cosa stava succedendo era che Il mio programma che ha aggiornato solo la tela dopo che il mio loop principale è stato eseguito per 100 Iterazioni e poi si fermò. Dopo aver aggiunto il Metodo sopra nel mio anello principale, improvvisamente ottengo gli aggiornamenti su tela su ogni loop del mio programma.

Il fatto che la tela non venga aggiornata finché il mio programma non avesse finito mi ha fatto pensare che l'aggiornamento su tela sia in esecuzione in un filo diverso che non ha priorità. (Ma sappiamo che JavaScript è single-filettato ).

La mia domanda è - Possiamo considerare un requestimimFrame un "rendimento" sul loop dell'applicazione per consentire il processo di evento di elaborare? posso ancora presumere che JavaScript sia single filettato?

Answer 1

Non sei specifico su come hai fatto la tua iterazione 1000 volte, ma presumo che tu ti permetta di essere istituito utilizzando un ciclo for o while (? correggimi se sbaglio ..).

Quando si esegue A per / mentre loop lo script sarà occupato-looping fino a quando tale loop (o ambito) è stato completato. Dato che JS è come conosci, non è possibile elaborare le cose come la coda degli eventi mentre sta facendo questo - non è nulla che non sarà in grado di aggiornare (incl. DOM) finché il loop non è terminato (in generale, ci sarà il browser specifico L'implementazione che consente gli aggiornamenti DOM se gli aggiornamenti DOM vengono eseguiti su un filo separato, ad esempio, ma questa è una cosa separata da JS).

Ora che hai implementato RAF stai facendo un singolo fotogramma iterating per . Ciò significa che il browser ha il tempo di elaborare la coda degli eventi asincronamente (non uguale a Multi-thread) a meno che il codice che hai elaborato nel loop sia stato anche occupato-loop per un po 'che creerebbe lo stesso scenario come il primo.

Avresti potuto usare anche setTimeout. Quale raf dà in modo diverso rispetto ad esempio setTimeout o setInterval è che è un'efficiente implementazione di basso livello di un meccanismo di timer in grado di sincronizzare al monitor VBLANK Periodo (Blanking verticale che la scheda video slaves attraverso un'opzione chiamata Vsync) - Significato in modalità normale della parola del monitor (tipicamente 60 Hz). Ciò consente di creare un'animazione liscia (ER) ed è per questo che si chiama richiesta * animazione * telaio in quanto questo è quello che è fatto principalmente per.

JS è ancora filettato single? Sì, questo non cambierà (l'unico modo per ottenere il multi-threading in JS è usando i lavoratori Web).

DA RAF cambia qualcosa? Non in quest'area - è un'alternativa più accurata e performante al setTimeout e si sincronizza in modo diverso ma è tutto. Subirà le stesse restrizioni del setTimeout che non è in grado di innescare se un ambito è occupato (da qui la parte request * parte del nome che implica alcuna garanzia) ma quando esegue il trigger sarà sincronizzato con la frequenza di aggiornamento del monitor. < / P >.