ブラウザーでは、1つの巨大なスプライトシートを使用するのが最善ですか、それとも多数（10000）の異なるPNGを使用するのが最善ですか？

jQueryでゲームを作成していますが、そこでは約10000個の32x32タイルを使用しています。今まで、それらをすべて別々に使用していました（スプライトシートなし）。平均的なマップでは、約2000タイル（場合によってはPNGを再利用しますが、すべて個別のdiv）を使用し、パフォーマンスの範囲は安定（Chrome）から少し遅れた（Firefox）までです。これらの各divは、CSSを使用して絶対に配置されます。新しいマップがロードされるときだけ、ティックごとに更新する必要はありません。

gameQueryのように、CSSバックグラウンドポジショニングを使用してdivにspritesheetメソッドを使用するとパフォーマンスが向上しますか？

前もって感謝します！

私のおすすめ

小さいPNGが多すぎると、多くのネットワークオーバーヘッドが追加されます（HTTPリクエストのサイズだけでなく、PNGヘッダー、そしておそらくさらに重要なことに、効率的に圧縮できないため）。一方、非常に大きなPNGには、ロードに時間がかかり、連続したメモリチャンクでメモリ（10,000タイルで40メガバイト）を永続的に保持する必要があるという欠点があります。

私は中間的な場所をお勧めします：いくつかの適度なサイズのPNG、例えばサイズ32×32の1024タイル。テーマごとにグループ化することもできます（たとえば、森林タイルのあるPNG、山タイルのあるPNG、都市タイルのあるPNG-ゲームのテーマはわかりませんが、アイデアはわかります）。

キャッシュ効率に関する注意

メモリアクセスの効率のため、スプライトシートの幅を広げすぎないでください。128×8192画像からのタイルのブリットは、8192×128画像からのブリットよりも常に高速です。

8192×128の画像の最初のタイルをブリットすることを想像してください。簡単にするために、1ピクセルが1バイトであると仮定します。最初の2行のピクセルは次のように配置されます（セルのメモリにはバイト番号が含まれます）。

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

したがって、最初のタイトルの最初の行をblitするために、ブラウザエンジンはにバイト0を31取得します。2行目をblitするには、バイト8192を8223取得する32行目までバイト253952を253983取得します。

処理されるバイトの総数は32×32です。ただし、合計メモリ範囲は253984バイトを超えています。最新のCPUでは、これは32または33のキャッシュストールを意味します。対照的に、イメージが128×8192の場合、メモリ範囲は4000バイトのみであり、キャッシュストールが2つ以下であることを意味します。

今日のCPUは非常に高速であるため、キャッシュストールは非常に高価であり、計算がハングします。そのため、少なくとも理論的には、8192×128画像の代わりに128×8192画像を使用すると、潜在的に8倍高速になります。実際には、これはブリットの実装方法に依存します。基礎となるエンジン自体が画像をタイルに分割して問題を軽減する可能性があります。

これを正確に説明するのは簡単ではなく、あまり詳しく説明することも期待していませんでした。それが理にかなっていることを願っています！

ラグの最大の原因の1つは、ブラウザー要求からサーバー、ブラウザーへのラウンドトリップであるため、1つの巨大なスプライトシートは（おそらく）より良いパフォーマンスを提供します。10,000のHTTP呼び出しは、10,000より大きいファイルを返す1つのHTTP呼び出しよりもはるかに長くかかります。

ゲームの構造と作成しているHTMLによっては、ラグを減らすために使用できる他のものがあるかもしれません。