En un navegador, ¿es mejor usar una gran hoja de sprites o muchos (10000) PNG diferentes?

Estoy creando un juego en jQuery, donde uso alrededor de 10000 fichas de 32x32. Hasta ahora, los he estado usando todos por separado (sin hoja de sprites). Un mapa promedio usa alrededor de 2000 mosaicos (a veces reutilizados PNG pero todos los divs separados) y el rendimiento varía de estable (Chrome) a un poco lento (Firefox). Cada uno de estos divs se posicionan absolutamente usando CSS. No es necesario que se actualicen cada tic, solo cuando se carga un nuevo mapa.

¿Sería mejor para el rendimiento usar métodos de hoja de sprites para los divs que usan posicionamiento de fondo CSS, como hace gameQuery?

¡Gracias de antemano!

Mi sugerencia

Demasiados PNG pequeños agregarán una gran sobrecarga de red (debido al tamaño de las solicitudes HTTP, pero también al encabezado PNG y, lo que es más importante, la incapacidad de comprimir de manera eficiente). Por otro lado, un PNG muy grande tiene los inconvenientes que lleva un tiempo cargar, y necesita permanecer permanentemente en la memoria (40 megabytes por 10,000 mosaicos) en una porción continua de memoria.

Recomiendo el término medio: varios PNG de tamaño razonable, por ejemplo 1024 mosaicos de tamaño 32 × 32 . Tal vez agrupados por tema (por ejemplo, un PNG con fichas de bosque, uno con fichas de montaña, otro con fichas de ciudad; no sé el tema de tu juego, pero entiendes la idea).

Nota sobre la eficiencia del caché

Debido a la eficiencia del acceso a la memoria, nunca debe hacer que sus hojas de sprites sean demasiado anchas. Los mosaicos brillantes de una imagen de 128 × 8192 siempre serán más rápidos que el borrado de una imagen de 8192 × 128.

Imagine que quiere borrar el primer mosaico en una imagen de 8192 × 128. En aras de la simplicidad, suponga que 1 píxel es 1 byte. Las primeras dos líneas de píxeles se presentan de esta manera (las celdas contienen su número de bytes en la memoria):

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

Así que con el fin de blit la primera línea del primer título, el motor del navegador recuperará bytes 0a31 . Para blit la segunda línea , se recuperará bytes 8192a8223 , y así sucesivamente hasta la línea de 32 bytes, donde 253952a253983 se recuperan.

El número total de bytes procesados ​​será 32 × 32. Sin embargo, el rango de memoria total es más de 253984 bytes. En una CPU moderna, esto significa 32 o 33 puestos de caché . Por el contrario, si la imagen fuera 128 × 8192, el rango de memoria sería de solo 4000 bytes, lo que significa que no más de dos puestos de caché.

Debido a que las CPU actuales son muy rápidas, las paradas de caché son muy caras y bloquean los cálculos. Por lo tanto, usar una imagen de 128 × 8192 en lugar de una imagen de 8192 × 128 es potencialmente 8 veces más rápido, al menos en teoría. En la práctica, esto dependerá de cómo se implemente el bliting: es posible que el motor subyacente mismo divida las imágenes en mosaicos para reducir el problema.

Esto no es fácil de explicar correctamente y no esperaba elaborar mucho. ¡Espero que tenga sentido!

Es probable que una gran hoja de sprites le brinde un mejor rendimiento, simplemente porque una de las principales causas del retraso es el viaje de ida y vuelta desde la solicitud del navegador al servidor al navegador. 10,000 llamadas HTTP tomarán mucho, mucho más tiempo que 1 llamada HTTP que devuelve un archivo que es 10,000 más grande.

Puede haber otras cosas que puede usar para disminuir el retraso, según la estructura del juego y el HTML que está creando.