Benchmarking grafis browser secara singkat: menggambar sebanyak mungkin sambil mempertahankan kecepatan frame yang lancar. Setelah kecepatan frame menurun, Anda akan mengetahui jumlah yang dapat digambar per frame. Akhir postingan. Tidak? Oke, saya akan menjelaskan lebih lanjut.
Contoh waktu! Berikut adalah cuplikan kode kecil dengan fungsi tick benchmark. Fungsi tick memanggil fungsi draw dengan beban gambar yang meningkat hingga gambar memerlukan waktu lebih dari 33 mdtk secara konsisten.
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);
Lihat contoh langsung di jsFiddle
Anda dapat melihat bagaimana benchmark terus menggambar lebih banyak hingga mencapai titik saat melambat. Ini adalah cara yang bagus dan sederhana untuk mengetahui seberapa banyak Anda dapat menggambar dengan kecepatan frame yang lancar. Anda juga dapat memasukkan fungsi gambar Anda sendiri ke contoh dan melakukan beberapa benchmark kustom.
Perhatian dan masalah umum saat menjalankan benchmark grafis browser
Jadi, jika contoh di atas adalah cara yang baik untuk melakukannya, apa cara yang tidak begitu baik? Cara yang membuat Anda melakukan benchmark pada hal-hal yang tidak terkait atau yang memberi Anda metrik performa aneh yang tampaknya tidak ada hubungannya dengan seberapa cepat aplikasi Anda berjalan. Terima kasih atas pertanyaannya. Berikut adalah dua jenis yang paling umum yang saya lihat di web.
Mengukur FPS maksimum: menggambar sedikit setiap frame dan mengukur FPS. Alat ini tidak berfungsi dengan baik untuk mengukur performa grafis di Chrome karena penerapan grafis yang mendasarinya disinkronkan dengan kecepatan refresh layar (sehingga Anda mendapatkan maksimal 60 pembaruan layar per detik). Mengukur kecepatan panggilan gambar juga tidak akan terlalu membantu karena sistem gambar Chrome menempatkan perintah gambar Anda ke dalam buffer perintah yang dijalankan pada refresh layar berikutnya.
Menggunakan setTimeout untuk mengukur performa grafis juga merupakan ide yang buruk. Interval setTimeout dibatasi hingga 4 md di browser, sehingga Anda hanya bisa mendapatkan 250 FPS. Secara historis, browser memiliki interval minimum yang berbeda, sehingga Anda mungkin memiliki benchmark gambar trivial yang sangat rusak yang menunjukkan browser A berjalan pada 250 FPS (interval minimum 4 md) dan browser B berjalan pada 100 FPS (interval minimum 10 md). Jelas A lebih cepat. Tidak. Bisa jadi B menjalankan kode gambar lebih cepat daripada A, misalnya A memerlukan waktu 3 md dan B memerlukan waktu 1 md. Tidak memengaruhi FPS, karena waktu gambar kurang dari interval setTimeout minimum. Dan jika browser dirender secara asinkron, semua taruhan akan dibatalkan. Jangan gunakan setTimeout kecuali jika Anda tahu apa yang Anda lakukan.
Cara melakukannya
Cara yang lebih baik untuk menjalankan benchmark adalah menggunakan beban gambar yang realistis dan mengalikankannya hingga kecepatan frame mulai menurun. Misalnya, jika Anda menulis game top-down dengan medan peta ubin, coba gambar peta ubin setiap frame dan lihat apakah game berjalan pada 60 FPS. Jika ya, tingkatkan pemuatan (gambar tilemap dua kali setiap frame, dengan penghapusan di antaranya). Terus tingkatkan hingga FPS turun ke tingkat stabil baru. Sekarang Anda tahu berapa banyak lapisan peta ubin yang dapat Anda gambar per frame.
Aplikasi grafis yang berbeda memiliki kebutuhan yang berbeda, jadi Anda harus menulis benchmark dengan mempertimbangkan hal tersebut. Ukur fitur grafis yang Anda gunakan di aplikasi. Jika Anda menemukan skenario yang lambat, coba kurangi hingga ke bagian kode terkecil yang mereproduksinya (dan kirim laporan bug di new.crbug.com jika seharusnya lebih cepat.)
Untuk melihat cara menulis kode grafis web berperforma tinggi, lihat presentasi Google I/O 2012 oleh Nat Duca dan Tom Wiltzius dari tim GPU Chrome.