Benchmarking von Browsergrafiken in Kürze: So viel wie möglich zeichnen und dabei eine flüssige Framerate beibehalten. Sobald die Framerate sinkt, wissen Sie, wie viel Sie pro Frame zeichnen können. Ende des Beitrags. Nein? Ok, ich erkläre das genauer.
Beispielzeit! Hier ist ein kleines Code-Snippet mit einer tick
-Funktion für Benchmarking. Die Funktion tick
ruft eine draw
-Funktion mit einer zunehmenden Auslastung auf, bis die Zeichnung immer länger als 33 ms dauert.
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);
Live-Beispiel in JSFiddle ansehen
Sie sehen, wie die Benchmark immer mehr zeichnet, bis sie sich verlangsamt. So können Sie ganz einfach herausfinden, wie viel Sie bei einer flüssigen Framerate zeichnen können. Sie können auch Ihre eigene Zeichenfunktion in das Beispiel einfügen und benutzerdefinierte Benchmarks durchführen.
Häufige Einschränkungen und Fallstricke beim Benchmarking von Browsergrafiken
Wenn das obige Beispiel die nette Art und Weise ist, wie man es macht, welche Möglichkeiten gibt es dann, die nicht so nett sind? Die Methoden, die dazu führen, dass Sie nicht zusammenhängende Dinge miteinander vergleichen oder seltsame Leistungsmesswerte erhalten, die anscheinend nichts mit der Geschwindigkeit Ihrer App zu tun haben. Gerne geschehen. Hier sind die beiden häufigsten, die ich im Web gesehen habe.
Maximale FPS messen: Zeichnen Sie in jedem Frame ein wenig und messen Sie die FPS. Er eignet sich nicht gut zur Messung der Grafikleistung in Chrome, da die zugrunde liegende Grafikimplementierung mit der Bildschirmaktualisierungsrate synchronisiert ist (d. h., es werden maximal 60 Bildschirmaktualisierungen pro Sekunde durchgeführt). Die Messung der Geschwindigkeit von Draw-Aufrufen ist ebenfalls nicht sehr hilfreich, da das Zeichensystem von Chrome Ihre Zeichenbefehle in einen Befehlsbuffer einfügt, der bei der nächsten Bildschirmaktualisierung ausgeführt wird.
Auch die Verwendung von setTimeout zum Messen der Grafikleistung ist keine gute Idee. Das Intervall von setTimeout ist in Browsern auf 4 ms begrenzt. Daher ist maximal eine Framerate von 250 fps möglich. Bisher hatten Browser unterschiedliche Mindestintervalle. Daher gab es möglicherweise einen sehr fehlerhaften Benchmark für einfache Zeichnungen, der zeigte, dass Browser A mit 250 FPS (4 ms Mindestintervall) und Browser B mit 100 FPS (10 ms Mindestintervall) ausgeführt wurde. A ist eindeutig schneller. Nein! Es kann gut sein, dass B den Zeichencode schneller als A ausgeführt hat, z. B. 3 ms bei A und 1 ms bei B. Das hat keine Auswirkungen auf die FPS, da die Zeichenzeit kürzer als das minimale Intervall von setTimeout ist. Und wenn der Browser asynchron gerendert wird, ist alles hinfällig. Verwenden Sie setTimeout nur, wenn Sie wissen, was Sie tun.
So gehts dann
Eine bessere Methode für einen Benchmark ist es, eine realistische Zeichenlast zu verwenden und sie zu multiplizieren, bis die Framerate zu ruckeln beginnt. Wenn Sie beispielsweise ein Top-Down-Spiel mit einem Tilemap-Terrain entwickeln, zeichnen Sie die Tilemap jeden Frame und prüfen Sie, ob es mit 60 FPS läuft. Falls ja, erhöhen Sie die Auslastung (zeichnen Sie die Tilemap zweimal pro Frame, mit einem Löschen dazwischen). Erhöhen Sie die Auflösung so lange, bis die FPS auf ein neues stabiles Niveau sinken. Jetzt wissen Sie, wie viele Ebenen der Tilemap Sie pro Frame zeichnen können.
Unterschiedliche Grafikanwendungen haben unterschiedliche Anforderungen. Berücksichtigen Sie dies bei der Erstellung Ihrer Benchmarks. Messen Sie die Grafikfunktionen, die Sie in Ihrer App verwenden. Wenn Sie ein langsames Szenario finden, versuchen Sie, es auf das kleinste Code-Snippet zu reduzieren, das es reproduziert. Reichen Sie einen Fehlerbericht unter new.crbug.com ein, wenn es schneller sein sollte.
Informationen zum Erstellen leistungsstarker Webgrafikcodes finden Sie im Vortrag von Nat Duca und Tom Wiltzius vom Chrome-GPU-Team auf der Google I/O 2012.