Benchmarking van browserafbeeldingen in een notendop: teken zoveel als je kunt met behoud van een vloeiende framesnelheid. Zodra je framerate daalt, weet je hoeveel je per frame kunt tekenen. Einde bericht. Nee? Oké, ik zal wat meer uitleggen.
Voorbeeld tijd! Hier is een klein codefragment met een benchmarking- tick . De tick -functie roept een draw functie aan met een toenemende draw-load totdat de draw consistent langer duurt dan 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);
Zie het live voorbeeld op jsFiddle
Je kunt zien hoe de benchmark steeds verder blijft trekken totdat hij het punt bereikt waarop hij vertraagt. Dit is een leuke en eenvoudige manier om erachter te komen hoeveel je kunt tekenen met een vloeiende framesnelheid. Je kunt ook je eigen tekenfunctie op het voorbeeld aansluiten en wat aangepaste benchmarking uitvoeren, jaja!
Veel voorkomende kanttekeningen en valkuilen bij het benchmarken van browserafbeeldingen
Dus als het bovenstaande voorbeeld de leuke manier is om het te doen, wat zijn dan de minder leuke manieren? De manieren die ertoe leiden dat u niet-gerelateerde zaken vergelijkt of dat u vreemde prestatiestatistieken krijgt die niets te maken lijken te hebben met hoe snel uw app draait. Fijn dat je het vraagt. Hier zijn de twee meest voorkomende die ik op internet heb gezien.
Max FPS meten: teken elk frame een klein beetje en meet de FPS. Het werkt niet goed voor het meten van de grafische prestaties in Chrome, omdat de onderliggende grafische implementatie wordt gesynchroniseerd met de vernieuwingsfrequentie van het scherm (zodat u maximaal 60 schermupdates per seconde krijgt). Het meten van de tekenaanroepsnelheid zal ook niet erg nuttig zijn, omdat het tekensysteem van Chrome uw tekenopdrachten in een opdrachtbuffer plaatst die wordt uitgevoerd bij de volgende schermvernieuwing.
Het gebruik van setTimeout voor het meten van grafische prestaties is een ander slecht idee. Het setTimeout-interval is in browsers beperkt tot 4 ms, dus het maximale dat u eruit kunt halen is 250 FPS. Historisch gezien hadden browsers verschillende minimumintervallen, dus het kan zijn dat je een heel slechte triviale draw-benchmark hebt gehad die liet zien dat browser A draaide op 250 FPS (4 ms min. interval) en browser B op 100 FPS (10 ms min. interval). Het is duidelijk dat A sneller is! Niet! Het zou heel goed kunnen zijn dat B de tekencode sneller uitvoerde dan A, bijvoorbeeld dat A 3 ms nodig had en B 1 ms. Heeft geen invloed op de FPS, omdat de tekentijd korter is dan het minimale setTimeout-interval. En als de browser asynchroon wordt weergegeven, zijn alle weddenschappen uitgeschakeld. Gebruik setTimeout niet tenzij u weet wat u doet.
Hoe moet je dat dan doen
Een betere manier om te benchmarken is door een realistische tekenbelasting te gebruiken en deze te vermenigvuldigen totdat de framesnelheid begint te puffen. Als je bijvoorbeeld een spel van bovenaf schrijft met een tegelkaart-terrein, probeer dan de tegelkaart elk frame te tekenen en kijk of deze op 60 FPS draait. Zo ja, verhoog dan de belasting (teken de tegelkaart twee keer per frame, met een vrije ruimte ertussen). Blijf stijgen totdat de FPS naar een nieuw stabiel niveau zakt. Nu weet je hoeveel lagen tegelkaart je per frame kunt tekenen.
Verschillende grafische applicaties hebben verschillende behoeften, dus u moet uw benchmarks met dat in gedachten schrijven. Meet de grafische functies die u in uw app gebruikt. Als je een langzaam scenario tegenkomt, probeer het dan terug te brengen tot het kleinste stukje code dat het reproduceert (en dien een bugrapport in op new.crbug.com als het sneller zou moeten zijn).
Om te zien hoe je krachtige webafbeeldingscode schrijft, bekijk je de Google I/O 2012-lezing van Nat Duca en Tom Wiltzius van het Chrome GPU-team.