Em um navegador, é melhor usar uma planilha enorme ou muitos (10000) PNGs diferentes?

Estou criando um jogo no jQuery, onde uso cerca de 10000 peças 32x32. Até agora, eu tenho usado todos eles separadamente (sem folha de sprite). Um mapa médio usa cerca de 2000 blocos (às vezes reutiliza PNGs, mas todas divs separadas) e o desempenho varia de estável (Chrome) a um pouco lento (Firefox). Cada uma dessas divs é posicionada absolutamente usando CSS. Eles não precisam ser atualizados a cada tick, apenas quando um novo mapa é carregado.

Seria melhor para o desempenho usar métodos de planilha para as divs usando o posicionamento em segundo plano CSS, como o gameQuery faz?

Agradeço antecipadamente!

Minha sugestão

Muitos PNGs pequenos adicionarão muita sobrecarga de rede (devido ao tamanho das solicitações HTTP, mas também ao cabeçalho PNG e, provavelmente ainda mais importante, à incapacidade de compactar com eficiência). Por outro lado, um PNG muito grande tem os inconvenientes que leva algum tempo para carregar e precisa permanecer permanentemente na memória (40 megabytes para 10.000 blocos) em um pedaço contínuo de memória.

Eu recomendo o meio termo: vários PNGs de tamanho razoável, por exemplo, 1024 blocos de tamanho 32 × 32 . Talvez agrupados por tema (por exemplo, um PNG com ladrilhos da floresta, um com ladrilhos de montanha, outro com ladrilhos da cidade - não sei o tema do seu jogo, mas você entendeu).

Nota sobre a eficiência do cache

Devido à eficiência do acesso à memória, você nunca deve tornar suas planilhas muito grandes. A combinação de blocos de uma imagem de 128 × 8192 sempre será mais rápida do que a combinação de uma imagem de 8192 × 128.

Imagine que você deseja mesclar o primeiro bloco em uma imagem de 8192 × 128. Por uma questão de simplicidade, suponha que 1 pixel seja 1 byte. As duas primeiras linhas de pixels são dispostas dessa maneira (as células contêm seu número de bytes na memória):

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

Portanto, para classificar a primeira linha do primeiro título, o mecanismo do navegador recuperará bytes 0para31 . Para blit a segunda linha , ele irá recuperar bytes 8192para8223 , e assim por diante até a linha 32 onde bytes 253952para253983 são recuperados.

O número total de bytes processados ​​será 32 × 32. No entanto, o intervalo total de memória é superior a 253984 bytes. Em uma CPU moderna, isso significa 32 ou 33 paradas de cache . Por outro lado, se a imagem tivesse 128 × 8192, o intervalo de memória seria de apenas 4000 bytes, o que significa não mais que duas paradas de cache.

Como as CPUs de hoje são muito rápidas, as paradas de cache são muito caras e paralisam os cálculos. Portanto, usar uma imagem de 128 × 8192 em vez de uma imagem de 8192 × 128 é potencialmente 8 vezes mais rápido, pelo menos em teoria. Na prática, isso dependerá de como a cegueira é implementada: é possível que o próprio mecanismo subjacente divida as imagens em blocos para reduzir o problema.

Isso não é fácil de explicar corretamente e eu não esperava elaborar muito. Eu espero que faça sentido!

Uma grande planilha (provavelmente) oferecerá melhor desempenho, simplesmente porque uma das maiores causas de atraso é a viagem de ida e volta da solicitação do navegador para o servidor para o navegador. 10.000 chamadas HTTP levarão muito, muito mais tempo do que uma chamada HTTP que retorna um arquivo 10.000 maior.

Pode haver outras coisas que você pode usar para diminuir o atraso, dependendo da estrutura do jogo e do HTML que você está criando.