Czy w przeglądarce najlepiej używać jednego ogromnego arkusza sprite lub wielu (10000) różnych plików PNG?

Tworzę grę w jQuery, w której używam około 10000 kafelków 32x32. Do tej pory korzystałem z nich osobno (bez arkusza ikonek). Przeciętna mapa wykorzystuje około 2000 kafelków (czasami ponownie używa PNG, ale wszystkie osobne pliki div), a zakres wydajności waha się od stabilnego (Chrome) do nieco opóźnionego (Firefox). Każdy z tych div jest pozycjonowany absolutnie za pomocą CSS. Nie muszą być aktualizowane co tyknięcie, tylko po załadowaniu nowej mapy.

Czy lepsza byłaby wydajność w przypadku korzystania z metod spriteheet dla div przy użyciu pozycjonowania tła CSS, podobnie jak w gameQuery?

Z góry dziękuję!

Moja sugestia

Zbyt wiele małych plików PNG spowoduje znaczne obciążenie sieci (ze względu na rozmiar żądań HTTP, ale także nagłówek PNG i, co ważniejsze, niemożność skutecznego skompresowania). Z drugiej strony, jeden bardzo duży plik PNG ma wady, których wczytywanie zajmuje trochę czasu i musi pozostać na stałe w pamięci (40 megabajtów na 10 000 kafelków) w ciągłej części pamięci.

Polecam środek: kilka rozsądnych rozmiarów PNG, na przykład 1024 kafelki o rozmiarze 32 × 32 . Może pogrupowane według motywu (na przykład PNG z kafelkami lasu, jeden z kafelkami gór, inny z kafelkami miasta - nie znam tematu twojej gry, ale masz pomysł).

Uwaga na temat wydajności pamięci podręcznej

Ze względu na wydajność dostępu do pamięci nigdy nie powinieneś robić zbyt dużych arkuszy. Blintowanie kafelków z obrazu 128 × 8192 zawsze będzie szybsze niż blending z obrazu 8192 × 128.

Wyobraź sobie, że chcesz wstawić pierwszy kafelek na obrazie 8192 × 128. Dla uproszczenia załóżmy, że 1 piksel to 1 bajt. Pierwsze dwie linie pikseli są rozmieszczone w ten sposób (komórki zawierają w pamięci liczbę bajtów):

┌────┬────┬───┬────┬──────────┬─────┐
│  0 │  1 │...│ 31 │   ....   │ 8191│ 1st line of pixels: bytes 0 to 8191
├────┼────┼───┼────┼──────────┼─────┤
│8192│8193│...│8223│   ....   │16383│ 2nd line of pixels: bytes 8192 to 16383
├────┼────┼───┼────┼──────────┼─────┤
│ .. │ .. │...│ .. │   ....   │ ... │

Aby więc wstawić pierwszy wiersz pierwszego tytułu, silnik przeglądarki pobierze bajty 0do31 . Aby Blit na drugą linię , będzie pobierać bajtów 8192do8223 , i tak dalej aż do linii 32, gdzie bajty 253952do253983 są pobierane.

Całkowita liczba przetworzonych bajtów będzie wynosić 32 × 32. Jednak całkowity zakres pamięci wynosi ponad 253984 bajtów. W nowoczesnym procesorze oznacza to 32 lub 33 przeciągnięcia pamięci podręcznej . Natomiast jeśli obraz miałby rozmiar 128 × 8192, zakres pamięci wynosiłby tylko 4000 bajtów, co oznacza nie więcej niż dwa przeciągnięcia pamięci podręcznej.

Ponieważ dzisiejsze procesory są bardzo szybkie, przeciągnięcia pamięci podręcznej są bardzo drogie i zawieszają się obliczenia. Zatem użycie obrazu 128 × 8192 zamiast obrazu 8192 × 128 jest potencjalnie 8 razy szybsze, przynajmniej w teorii. W praktyce będzie to zależeć od tego, w jaki sposób realizowane jest bltingowanie: możliwe jest, że sam silnik dzieli obrazy na kafelki, aby zmniejszyć problem.

Nie jest to łatwe do prawidłowego wyjaśnienia i nie spodziewałem się, że będę dużo opracowywać. Mam nadzieję, że to ma sens!

Ogromny arkusz spriterzy (prawdopodobnie) zapewni lepszą wydajność, po prostu dlatego, że jedną z największych przyczyn opóźnień jest podróż w obie strony od żądania przeglądarki do serwera do przeglądarki. 10 000 połączeń HTTP zajmie dużo, znacznie dłużej niż 1 połączenie HTTP, które zwraca plik, który jest o 10 000 większy.

Mogą być inne rzeczy, których możesz użyć, aby zmniejszyć opóźnienie, w zależności od struktury gry i tworzonego HTML.