Analiza porównawcza grafiki w przeglądarce w pigułce: rysuj tyle, ile się da, zachowując płynną liczbę klatek. Gdy liczba klatek się zmniejszy, wiesz, ile uda Ci się narysować w każdej klatce. Koniec posta. Nie? Jeszcze trochę wyjaśnię.
Przykładowy czas! Oto krótki fragment kodu z funkcją analizy porównawczej tick. Funkcja tick wywołuje funkcję draw o rosnącym obciążeniu, aż pobieranie będzie trwać konsekwentnie dłużej niż 33 ms.
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);
Zobacz przykład online na jsFiddle
W ten sposób można zobaczyć, jak test porównawczy zyskuje coraz więcej wartości, aż do osiągnięcia poziomu, w którym zaczyna spadać. To miły i prosty sposób na sprawdzenie, ile możesz narysować przy płynnej liczbie klatek. Możesz też dodać do przykładu własną funkcję rysowania i wprowadzić własną analizę porównawczą.
Typowe zastrzeżenia i problemy związane z analizą porównawczą grafiki w przeglądarkach
Jeśli więc zastosujesz się do powyższego przykładu, to na jaki sposób nie jest on zbyt ładny? Sposoby, które umożliwiają przeprowadzanie testów porównawczych niepowiązanych elementów lub generowanie dziwnych danych o skuteczności, które nie mają nic wspólnego z szybkością działania aplikacji. Cieszę się, że pytasz. Oto 2 najpowszechniejsze strony w internecie.
Pomiar maksymalnej liczby klatek na sekundę: rysuj fragmentem każdej klatki i zmierz liczbę klatek na sekundę. Nie sprawdza się on w mierzeniu wydajności grafiki w Chrome, ponieważ podstawowa implementacja grafiki jest synchronizowana z częstotliwością odświeżania ekranu (więc uzyskasz maksymalnie 60 aktualizacji ekranu na sekundę). Pomiar szybkości wywoływania rysowania nie będzie zbyt pomocny, ponieważ system rysowania w Chrome umieszcza polecenia rysowania w buforze poleceń, które są wykonywane przy następnym odświeżeniu ekranu.
Kolejnym złym pomysłem jest użycie setTimeout do pomiaru wydajności grafiki. Odstęp czasu setTimeout jest w przeglądarkach ograniczony do 4 ms, więc maksymalnie możesz go wykorzystać do 250 kl./s. W przeszłości przeglądarki miały różne minimalne odstępy, więc test porównawczy pokazujeł, że przeglądarka A działała z szybkością 250 FPS (odstęp 4 ms), a przeglądarka B – z prędkością 100 FPS (10 ms min.). Bez wątpienia A jest szybsze! Nie. Możliwe, że system B uruchomił kod rysowania szybciej niż A, np. A trwał 3 ms, a B – 1 ms. Nie ma to wpływu na liczbę klatek na sekundę, ponieważ czas rysowania jest krótszy niż minimalny ustawiony odstęp czasu. Jeśli przeglądarka renderuje się asynchronicznie, wszystkie opcje są wyłączone. Nie używaj funkcji setTimeout, jeśli nie wiesz, co robisz.
Jak to zrobić
Lepszym sposobem porównawczym jest użycie realistycznego obciążenia rysunków i pomnożenie wyniku aż do uzyskania zmniejszonej liczby klatek. Jeśli na przykład piszesz grę z widokiem od góry i mapą terenu, narysuj ją na każdej klatce i sprawdź, czy obraz działa z szybkością 60 kl./s. Jeśli tak, zwiększ obciążenie (narysuj mapę kafelków dwa razy w każdej klatce, oddzielając je wyraźnymi fragmentami). Kontynuuj, aż liczba FPS spadnie do nowego stabilnego poziomu. Wiesz już, ile warstw mapy kafelków możesz narysować w każdej ramce.
Różne aplikacje graficzne mają różne potrzeby, więc należy pisać testy porównawcze. Sprawdź funkcje graficzne używane w aplikacji. W przypadku powolnego działania spróbuj ograniczyć go do najmniejszego fragmentu kodu, który go odtwarza (i prześlij raport o błędzie na new.crbug.com, jeśli powinno to działać szybciej).
Aby dowiedzieć się, jak pisać kod wydajnej grafiki internetowej, obejrzyj prezentację Google I/O 2012, którą Nat Duca i Tom Wiltzius z zespołu GPU Chrome omówili podczas Google I/O 2012.