Benchmarking della grafica del browser in poche parole: disegna il più possibile mantenendo una frequenza frame uniforme. Quando la frequenza frame diminuisce, sai quanto puoi disegnare per frame. Fine del post. No? Ok, ti spiego meglio.
Esempio di tempo. Ecco un piccolo snippet di codice con una funzione di benchmarking tick. La funzione tick chiama una funzione draw con un carico di disegno crescente finché il disegno non richiede in modo costante più di 33 ms.
var t, previousTime;
var drawLoad = 1;
var slowCount = 0;
var maxSlow = 10;
// Note, you might need to polyfill performance.now and requestAnimationFrame
t = previousTime = performance.now();
var tick = function() {
var maximumFrameTime = 1000/30; // 30 FPS
t = performance.now();
var elapsed = t - previousTime;
previousTime = t;
if (elapsed < maximumFrameTime || slowCount < maxSlow) {
if (elapsed < maximumFrameTime) {
drawLoad+=10;
} else {
slowCount++;
}
draw(drawLoad);
requestAnimationFrame(tick);
} else {
// found maximum sustainable load at 30 FPS
document.getElementById('res').innerHTML = ("could draw "+(drawLoad)+" in " +
maximumFrameTime + " ms");
}
};
requestAnimationFrame(tick);
Guarda l'esempio dal vivo su jsFiddle
Puoi vedere come il benchmark continua a crescere fino a raggiungere il punto in cui rallenta. Si tratta di un modo semplice e pratico per capire quanto puoi disegnare a una frequenza fotogrammi fluida. Puoi anche collegare la tua funzione di disegno all'esempio ed eseguire un benchmarking personalizzato.
Precauzioni e insidie comuni durante il benchmarking della grafica del browser
Quindi, se l'esempio riportato sopra è il modo corretto per farlo, quali sono i modi meno corretti? I metodi che ti portano a eseguire benchmark di cose non correlate o che ti forniscono metriche di prestazioni strane che non sembrano avere nulla a che fare con la velocità di esecuzione dell'app. Mi fa piacere che tu abbia chiesto. Ecco i due problemi più comuni che ho visto sul web.
Misurare il numero massimo di FPS: disegna un po' in ogni frame e misura i FPS. Non funziona bene per misurare le prestazioni grafiche su Chrome perché l'implementazione grafica sottostante è sincronizzata con la frequenza di aggiornamento dello schermo (quindi ottieni un massimo di 60 aggiornamenti dello schermo al secondo). Anche la misurazione della velocità delle chiamate di disegno non è molto utile, in quanto il sistema di disegno di Chrome inserisce i comandi di disegno in un buffer dei comandi che viene eseguito al successivo aggiornamento dello schermo.
Anche l'utilizzo di setTimeout per misurare le prestazioni della grafica è una cattiva idea. L'intervallo di setTimeout è limitato a 4 ms nei browser, quindi il massimo che puoi ottenere è 250 FPS. In passato, i browser avevano intervalli minimi diversi, quindi potresti aver avuto un benchmark di disegno banale molto errato che mostrava il browser A in esecuzione a 250 FPS (intervallo minimo di 4 ms) e il browser B a 100 FPS (intervallo minimo di 10 ms). È chiaro che A è più veloce. No! È possibile che B abbia eseguito il codice di disegno più velocemente di A, ad esempio A abbia impiegato 3 ms e B 1 ms. Non influisce sui FPS, poiché il tempo di disegno è inferiore all'intervallo minimo di setTimeout. Se il browser esegue il rendering in modo asincrono, non c'è nulla da fare. Non utilizzare setTimeout se non sai cosa stai facendo.
Come procedere
Un modo migliore per eseguire il benchmark è utilizzare un carico di disegno realistico e moltiplicarlo fino a quando la frequenza dei fotogrammi non inizia a rallentare. Ad esempio, se stai scrivendo un gioco in visuale dall'alto con un terreno in tilemap, prova a disegnare la tilemap ogni frame e controlla se funziona a 60 FPS. In caso affermativo, aumenta il carico (disegna la mappa a riquadri due volte ogni frame, con una cancellazione intermedia). Continua ad aumentare fino a quando gli FPS non scendono a un nuovo livello stabile. Ora sai quanti livelli di mappa a riquadri puoi disegnare per frame.
Le applicazioni grafiche hanno esigenze diverse, quindi devi scrivere i benchmark tenendo conto di questo aspetto. Misura le funzionalità grafiche che utilizzi nella tua app. Quando trovi uno scenario lento, prova a ridurlo al frammento di codice più piccolo che lo riproduce (e invia una segnalazione di bug all'indirizzo new.crbug.com se dovrebbe essere più veloce).
Per scoprire come scrivere codice di grafica web ad alte prestazioni, dai un'occhiata al talk di Google I/O 2012 di Nat Duca e Tom Wiltzius del team GPU di Chrome.