Cara mengukur performa grafis browser

Ilmari Heikkinen

Membuat tolok ukur grafis browser secara singkat: gambar sebanyak mungkin sambil mempertahankan kecepatan frame yang lancar. Setelah kecepatan frame turun, Anda tahu berapa banyak yang dapat digambar per frame. Akhir postingan. Tidak? Oke, saya akan menjelaskan lebih banyak.

Waktu contoh! Berikut ini cuplikan kode kecil dengan fungsi tick benchmark. Fungsi tick memanggil fungsi draw dengan beban gambar yang meningkat hingga gambar memerlukan waktu lebih lama dari 33 milidetik 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 yang melambat. Ini adalah cara yang bagus dan sederhana untuk mengetahui seberapa banyak Anda dapat menggambar pada kecepatan frame yang lancar. Anda juga dapat menyertakan fungsi gambar Anda sendiri ke contoh tersebut dan melakukan beberapa tolok ukur kustom.

Peringatan dan kesalahan umum saat membuat tolok ukur grafis browser

Jadi, jika contoh di atas adalah cara yang bagus untuk melakukannya, apa cara yang tidak begitu baik? Cara Anda membuat tolok ukur terhadap hal-hal yang tidak terkait atau memberi Anda metrik performa aneh yang tampaknya tidak ada hubungannya dengan seberapa cepat aplikasi Anda berjalan. Pertanyaan bagus, berikut dua pertanyaan paling umum yang pernah saya lihat di web.

Mengukur FPS maks: gambar sedikit setiap frame dan ukur FPS. Fitur ini tidak berfungsi dengan baik untuk mengukur performa grafis di Chrome karena implementasi grafis yang mendasarinya disinkronkan dengan kecepatan refresh layar (sehingga Anda mendapatkan update layar maksimal 60 per detik). Mengukur kecepatan panggilan gambar juga tidak akan terlalu membantu karena sistem gambar Chrome menempatkan perintah menggambar Anda ke dalam buffering perintah yang dijalankan pada pemuatan ulang layar berikutnya.

Menggunakan setTimeout untuk mengukur performa grafis adalah ide yang buruk. Interval setTimeout dibatasi hingga 4 md di browser, sehingga jumlah maksimal yang bisa Anda dapatkan adalah 250 FPS. Secara historis, browser memiliki interval minimum yang berbeda, jadi Anda mungkin memiliki benchmark gambar sepele yang sangat rusak yang menunjukkan browser A berjalan pada 250 FPS (interval minimum 4 md) dan browser B berjalan pada 100 FPS (interval minimal 10 md). Jelas A lebih cepat. Tidak. Bisa jadi B menjalankan kode gambar lebih cepat daripada A, misalkan A membutuhkan 3 md dan B membutuhkan 1 md. Tidak memengaruhi FPS, karena waktu menggambar kurang dari interval setTimeout minimum. Dan jika browser merender secara asinkron, semua taruhan dinonaktifkan. Jangan menggunakan setTimeout kecuali Anda tahu apa yang Anda lakukan.

Cara melakukannya nanti

Cara yang lebih baik untuk menjalankan benchmark adalah menggunakan beban gambar yang realistis dan mengalikannya hingga kecepatan frame mulai berubah. Misalnya, jika Anda menulis game top-down dengan medan peta ubin, coba gambar peta ubin setiap frame dan lihat apakah petanya berjalan pada 60 FPS. Jika ya, tambah beban (gambar peta ubin dua kali setiap frame, dengan tanda jelas di antaranya). Terus tingkatkan hingga FPS turun ke level stabil yang baru. Sekarang Anda tahu berapa banyak lapisan peta ubin yang dapat digambar per bingkai.

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. Saat Anda menemukan skenario yang lambat, coba kurangi ke bagian kode terkecil yang mereproduksinya (dan ajukan laporan bug ke new.crbug.com jika seharusnya lebih cepat.)

Untuk mengetahui cara menulis kode grafis web berperforma tinggi, lihat diskusi Google I/O 2012 oleh Nat Duca dan Tom Wiltzius dari tim GPU Chrome.