ブラウザ グラフィックのベンチマークの概要: 滑らかなフレームレートを維持しながら、可能な限り多く描画します。フレームレートが低下すると、1 フレームあたりに描画できる量がわかります。投稿の末尾。それでは、もう少し説明します。
例:ベンチマーク tick 関数を含む小さなコード スニペットを以下に示します。tick 関数は、描画負荷が一貫して 33 ミリ秒を超えるまで、描画負荷を増加させて draw 関数を呼び出します。
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);
jsFiddle のライブ例をご覧ください。
ベンチマークが減速するポイントに達するまでさらに描画を続けることがわかります。これは、スムーズなフレームレートでどれだけ描画できるかを把握するのに役立つ便利な方法です。また、独自の描画関数をサンプルに挿入して、カスタムのベンチマークを行うこともできます。
ブラウザのグラフィックのベンチマークを行う際の一般的な注意事項と注意点
さて、上記の例が適切な方法だとしたら、良くない方法にはどのようなものがあるでしょうか。無関係なベンチマークを行う原因となったり、アプリの実行速度とは関係がないと思われる異常なパフォーマンス指標を取得したりすること。こちらは、ウェブでよく寄せられる質問です。
最大 FPS の測定: フレームごとに少しずつ描画して、FPS を測定します。基になるグラフィックの実装が画面のリフレッシュ レートと同期されるため（1 秒あたり最大 60 件の画面更新が可能）、Chrome でのグラフィックのパフォーマンスの測定には適していません。描画呼び出し速度の測定はあまり役に立ちません。Chrome の描画システムは、描画コマンドをコマンド バッファに格納し、次の画面更新時に実行します。
また、グラフィックのパフォーマンスを測定するために setTimeout を使用することもおすすめできません。ブラウザでは、setTimeout の間隔が 4 ミリ秒に制限されているため、可能な最大値は 250 FPS です。従来、ブラウザの最小間隔は異なるため、ブラウザ A は 250 FPS（最小間隔 4 ミリ秒）で動作し、ブラウザ B は 100 FPS（最小間隔 10 ミリ秒）で動作しているという、非常に壊れた自明な描画ベンチマークがあったかもしれません。A の方が速いのは明らか！いいえ。たとえば、A に 3 ミリ秒、B に 1 ミリ秒かかったなど、B が A よりも速く描画コードを実行した可能性も考えられます。描画時間は setTimeout の最小間隔よりも短いため、FPS には影響しません。また、ブラウザが非同期でレンダリングされる場合は、すべての賭け金が無効になります。何を行っているか把握していない限り、setTimeout を使用しないでください。
その後の手順
ベンチマークを行うより適切な方法は、現実的な描画負荷を使用し、フレームレートが変動し始めるまでその負荷を乗算することです。たとえば、タイルマップの地形を使用するトップダウン ゲームを作成する場合は、タイルマップをフレームごとに描画して、60 FPS で動作するかどうかを確認してみましょう。「はい」の場合、負荷を増やします（タイルマップをフレームごとに 2 回、間にクリアな状態で描画します）。FPS が新しい安定したレベルまで下がるまで増加を続けます。これで、フレームごとに描画できるタイルマップのレイヤの数がわかります。
グラフィック アプリケーションによってニーズは異なるため、その点を念頭に置いてベンチマークを作成する必要があります。アプリで使用しているグラフィック機能を測定します。低速なシナリオが見つかった場合は、そのシナリオを再現する最小のコードにまで縮小してみます（より速くなる必要がある場合は、new.crbug.com でバグレポートを提出してください）。
高性能なウェブ グラフィック コードの記述方法については、Chrome GPU チームの Nat Duca と Tom Wiltzius による Google I/O 2012 の講演をご覧ください。