Tarayıcı grafiklerinin performansını ölçme

Ilmari Heikkinen

Tarayıcı grafiklerini özetle karşılaştırma: Akıcı bir kare hızıyla mümkün olduğunca çok çizim yapın. Kare hızınız düştüğünde kare başına ne kadar çizim yapabileceğinizi biliyorsunuz. Yayının sonu. Cevabınız hayır mı? Peki, biraz daha açıklayacağım.

Örnek süre! Aşağıda, karşılaştırma tick işlevine sahip küçük bir kod snippet'i verilmiştir. tick işlevi, çizim tutarlı olarak 33 ms'den uzun sürene kadar çizim yükü artışı olan bir draw işlevini çağırır.

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'daki canlı örneği inceleyin

Karşılaştırmanın yavaşladığı noktaya kadara kadar çizim yapmaya nasıl devam ettiğini görebilirsiniz. Bu, akıcı bir kare hızında ne kadar çizim yapabileceğinizi anlamanın güzel ve basit bir yoludur. Ayrıca, örneğe kendi çizim fonksiyonunuzu da ekleyebilir ve bazı özel karşılaştırmalar yapabilirsiniz.

Tarayıcı grafiklerini karşılaştırırken dikkat edilmesi gereken genel uyarılar ve tehlikeler

Peki, yukarıdaki örnek bunu yapmanın güzel bir yoluysa, bu kadar da hoş olmayan yöntemler neler? Uygulamanızın çalışma hızıyla hiçbir ilgisi olmayan, alakasız şeyleri karşılaştırmanıza neden olan veya tuhaf performans metrikleri görmenizi sağlayan yöntemler. Sormanıza sevindim. Web'de en sık gördüğüm ikisini burada bulabilirsiniz.

Maksimum FPS'yi ölçme: Her kareden biraz biraz çizin ve FPS'yi ölçün. Temel grafik uygulaması ekran yenileme hızıyla senkronize edildiğinden saniyede maksimum 60 ekran güncellemesi aldığınız için bu özellik Chrome'daki grafik performansını ölçmekte iyi sonuç vermez. Chrome'un çizim sistemi çizim komutlarınızı sonraki ekran yenilemesinde çalıştırılacak bir komut arabelleğine yerleştirdiğinden çizim çağrısı hızını ölçmek de pek yararlı olmaz.

Grafik performansını ölçmek için setTimeout kullanmak da kötü bir fikirdir. setTimeout aralığı tarayıcılarda 4 ms ile sınırlandırılır, dolayısıyla en fazla 250 FPS'den faydalanabilirsiniz. Geçmişte, tarayıcıların minimum aralıkları farklıydı. Bu yüzden, A tarayıcısının 250 FPS (4 ms'lik aralık) ile 100 FPS'de (dk. 10 ms. aralık) çalıştığını gösteren çok bozuk küçük çekilme kriteriniz olabilir. Açıkçası A daha hızlıdır! Hayır! B, çizim kodunu A'dan daha hızlı çalıştırmış olabilir (A'nın 3 ms, B'nin 1 ms sürdü). Çizim süresi minimum setTimeout aralığından kısa olduğu için FPS'yi etkilemez. Ayrıca, tarayıcı eşzamansız olarak görüntüler oluşturuyorsa tüm sonuçlar hatalıdır. Ne yaptığınızı bilmiyorsanız setTimeout'u kullanmayın.

Nasıl yapılır?

Gerçekçi bir çizim yükü kullanmak ve bunu, kare hızı kesilmeye başlayana kadar çarpmak daha iyi bir karşılaştırma yöntemidir. Örneğin, karo haritası araziye sahip yukarıdan aşağıya bir oyun yazıyorsanız, her kareyi çizmeyi ve 60 FPS'de çalışıp çalışmadığına bakmayı deneyin. Cevabınız evet ise yükü artırın (tilemap'i her karede iki kez, aralarında net bir şekilde olacak şekilde çizin). FPS yeni bir sabit seviyeye düşene kadar yükseltmeye devam edin. Artık her kare için kaç tane karo haritası katmanı çizebileceğinizi biliyorsunuz.

Farklı grafik uygulamalarının farklı ihtiyaçları vardır, dolayısıyla karşılaştırmalarınızı yazarken bunu göz önünde bulundurmalısınız. Uygulamanızda kullandığınız grafik özelliklerini ölçün. Yavaş bir senaryo gördüğünüzde, bu senaryoyu yeniden oluşturan en küçük kod parçasına indirmeyi deneyin (ve daha hızlı olacaksa new.crbug.com adresinden bir hata raporu gönderin.)

Yüksek performanslı web grafik kodunun nasıl yazılacağını görmek için Chrome GPU ekibinden Nat Duca ve Tom Wiltzius'un yaptığı Google I/O 2012 konuşmasına göz atın.