ブラウザ グラフィックのベンチマークの概要: スムーズなフレームレートを維持しながら、できるだけ多くのものを描画します。フレームレートが低下すると、フレームごとに描画できる量がわかります。投稿の終了。思いませんか？詳しく説明します。
例:ベンチマーク tick 関数を含む簡単なコード スニペットを次に示します。tick 関数は、描画負荷を増やしながら draw 関数を呼び出し、描画に 33 ミリ秒を超える時間がかかるようになります。
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 のライブ例をご覧ください。
ベンチマークが、速度が低下するポイントに達するまで、どんどん描画し続けている様子を確認できます。これは、スムーズなフレームレートで描画できる量を簡単に把握できる方法です。また、独自の描画関数をサンプルにプラグインして、カスタム ベンチマークを行うこともできます。
ブラウザ グラフィックをベンチマークする際の一般的な注意事項と落とし穴
上記の例が適切な方法だとすると、不適切な方法とはどのようなものなのでしょうか。無関係なものをベンチマークする方法や、アプリの実行速度とは何の関係もないように見える奇妙なパフォーマンス指標が得られる方法。お問い合わせいただきありがとうございます。ウェブ上でよく見られる 2 つの問題をご紹介します。
最大 FPS の測定: フレームごとに少しずつ描画して FPS を測定します。基盤となるグラフィック実装が画面の更新レートと同期されるため（1 秒あたり最大 60 回の画面更新）、Chrome のグラフィック パフォーマンスの測定には適していません。Chrome の描画システムでは、描画コマンドがコマンド バッファに格納され、次回の画面更新時に実行されるため、描画呼び出し速度を測定してもあまり意味がありません。
また、setTimeout を使用してグラフィック パフォーマンスを測定することもおすすめしません。ブラウザでは setTimeout の間隔の上限が 4 ミリ秒に設定されているため、最大で 250 FPS しか得られません。これまで、ブラウザによって最小間隔が異なっていたため、ブラウザ A が 250 FPS（最小間隔 4 ms）で実行され、ブラウザ B が 100 FPS（最小間隔 10 ms）で実行されるという、非常に不正確な単純な描画ベンチマークが存在する可能性がありました。明らかに 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 の講演をご覧ください。