브라우저 그래픽 벤치마킹 요약: 부드러운 프레임 속도를 유지하면서 최대한 많이 그려보세요. 프레임 속도가 떨어지면 프레임당 얼마나 그릴 수 있는지 알 수 있습니다. 게시물 끝입니다. 없으시다면 알겠습니다. 자세히 설명해 드리겠습니다.
시간 예시! 다음은 벤치마킹 tick 함수가 포함된 작은 코드 스니펫입니다. tick 함수는 그리기가 일관되게 33ms보다 오래 걸릴 때까지 그리기 로드가 증가함에 따라 draw 함수를 호출합니다.
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를 측정합니다. 기본 그래픽 구현이 화면 재생 빈도와 동기화되므로 (따라서 초당 최대 60회의 화면 업데이트) Chrome에서 그래픽 성능을 측정하는 데는 적합하지 않습니다. 그리기 호출 속도를 측정하는 것은 그다지 유용하지 않습니다. Chrome의 그리기 시스템은 그리기 명령을 다음 화면 새로고침 시 실행되는 명령 버퍼에 저장하기 때문입니다.
그래픽 성능을 측정하기 위해 setTimeout을 사용하는 것도 좋지 않습니다. 브라우저의 setTimeout 간격은 4ms로 제한되므로 최대 250FPS를 사용할 수 있습니다. 이전에는 브라우저의 최소 간격이 달랐으므로 브라우저 A는 250FPS (최소 4ms 간격)로 실행되고 브라우저 B는 100FPS (최소 간격 10ms)로 실행되는 것을 보여주는 아주 사소한 그리기 벤치마크가 있었을 수 있습니다. 확실히 A가 더 빠른 게 분명해! 아닙니다. A는 3ms, B는 1ms가 걸렸다고 할 때 B는 A보다 더 빠르게 그리기 코드를 실행했을 수 있습니다. 그리기 시간이 최소 setTimeout 간격보다 짧으므로 FPS에 영향을 미치지 않습니다. 그리고 브라우저가 비동기식으로 렌더링된다면 모든 투자가 중단됩니다. 잘 모르는 경우 setTimeout을 사용하지 않습니다.
그때 취할 수 있는 조치
벤치마킹하는 더 좋은 방법은 현실적인 그리기 로드를 사용하여 프레임 속도가 느려지기 시작할 때까지 곱하는 것입니다. 예를 들어 타일맵 지형이 있는 하향식 게임을 개발 중이라면 프레임마다 타일맵을 그리고 60FPS로 실행되는지 확인해 보세요. '예'인 경우 부하를 늘립니다 (프레임마다 타일맵을 두 번, 그 사이에는 명확히 그리세요). FPS가 새로운 안정적인 수준으로 떨어질 때까지 계속 늘립니다. 이제 프레임당 그릴 수 있는 타일맵 레이어를 알게 되었습니다.
그래픽 애플리케이션마다 요구사항이 다르므로 이를 염두에 두고 벤치마크를 작성해야 합니다. 앱에서 사용 중인 그래픽 기능을 측정합니다. 느린 시나리오를 발견하면 이를 재현하는 가장 작은 코드 조각으로 줄여 봅니다. 더 빨라야 한다면 new.crbug.com에서 버그 신고를 제출하세요.
고성능 웹 그래픽 코드를 작성하는 방법을 보려면 Chrome GPU팀에서 발표한 Nat Duca와 Tom Wiltzius의 Google I/O 2012 강연을 확인해 보세요.