如何評估瀏覽器圖像效能

Ilmari Heikkinen

簡單來說,瀏覽器圖形基準測試就是盡可能多地繪製圖形,同時維持流暢的影格速率。一旦影格速率下降,您就會知道每個影格可繪製的內容量。結束貼文。沒有?好的,我會進一步說明。

舉例說明!以下是包含基準測試 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 上的即時範例

您可以看到基準測試如何不斷繪製,直到達到速度變慢的點為止。這是一種簡單又實用的方式,可讓您瞭解在流暢的幀率下,您可以繪製多少內容。您也可以將自己的繪圖函式插入範例,並進行一些自訂基準測試,太棒了!

進行瀏覽器圖形基準測試時的常見注意事項和陷阱

因此,如果上述範例是正確的做法,那麼哪些做法是不正確的?導致您對不相關項目進行基準測試,或產生與應用程式執行速度無關的奇怪效能指標。很高興你問了這個問題,以下是我在網路上看到的兩個最常見問題。

測量最高 FPS:每個影格只繪製一點點內容,並測量 FPS。這項測試無法有效評估 Chrome 的圖像效能,因為基礎圖像實作會與螢幕更新率同步 (因此每秒最多可獲得 60 次螢幕更新)。測量繪製呼叫速度也不太有幫助,因為 Chrome 的繪圖系統會將繪圖指令放入指令緩衝區,在下次螢幕重新整理時執行。

使用 setTimeout 評估繪圖效能也是另一個不良做法。在瀏覽器中,setTimeout 間隔的上限為 4 毫秒,因此最多只能達到 250 FPS。以往瀏覽器的最小間隔不同,因此您可能會看到非常不準確的簡單繪圖基準測試,顯示瀏覽器 A 以 250 FPS (最小間隔 4 毫秒) 執行,而瀏覽器 B 以 100 FPS (最小間隔 10 毫秒) 執行。很明顯,A 的速度比較快!不!很可能是 B 執行繪圖程式碼的速度比 A 快,假設 A 需要 3 毫秒,B 則需要 1 毫秒。由於繪圖時間小於最小 setTimeout 間隔,因此不會影響 FPS。如果瀏覽器以非同步方式算繪,則一切都會失效。因此,除非您瞭解自己在做什麼,否則請勿使用 setTimeout。

那麼該如何進行

比較理想的基準測試方式,是使用實際的繪圖負載,並加倍疊加,直到影格速率開始下降為止。舉例來說,如果您要編寫使用圖塊地形的俯瞰式遊戲,請嘗試在每個影格繪製圖塊地形,看看是否能以 60 FPS 執行。如果是,請增加負載 (每個影格繪製地圖兩次,中間清除)。繼續增加,直到 FPS 降至新的穩定水平。您現在已瞭解每個影格可繪製多少個圖塊地圖層。

不同圖形應用程式的需求不同,因此您應在編寫基準測試時考量這點。評估應用程式中使用的圖形功能。如果發現速度緩慢的情況,請盡量縮減重現該情況的程式碼,並在 new.crbug.com 提交錯誤報告 (如果速度應該更快的話)。

如要瞭解如何編寫高效能網頁圖形程式碼,請參閱 Chrome GPU 團隊的 Nat Duca 和 Tom Wiltzius 在 Google I/O 2012 的演講。