为什么游戏开发者要把许多图片放在一张大图片里？

Question

多年来，我经常问自己，为什么游戏开发人员将许多小图像放在一个大图像中。但并不是只有游戏开发人员才这么做。我还记得很好的旧的Winamp MP3播放器有一个用户界面设计文件，它只是一个巨大的图像，其中包含许多小图像。

我也见过一些像ext.js这样的大型javascript GUI库使用这种技术。在ext.js中，有一个包含许多小图像的大图像。

我注意到的一件事是:无论我的PNG图像有多小，Mac上的Finder总是告诉我它至少需要4kb。如果你只有10个像素，这是非常多的。

所以这样做是因为将20个或更多的小图像存储到一个大图像中要比拥有20个单独的文件更有内存效率，每个文件可能都有自己的头和元数据？

是不是因为在文件系统上定位文件既昂贵又慢，因此在加载到内存中后，只定位一个大图像，然后将其拆分成较小的图像，速度会快得多？

或者是懒惰，因为想到这么多的文件名是乏味的？

这项技术有名字吗？在运行时，这些小图像是如何与大图像分开的呢？

Answer 1

这些答案没有一个是正确的。我们将多个图像打包成一个大的“精灵图”或“纹理图集”的原因是为了避免在渲染过程中交换纹理。

当你从一个图像(纹理)绘制并切换到另一个图像时，OpenGL和Direct-X的性能会受到影响，所以我们将多个图像打包到一个大图像中，然后我们可以绘制几个(或数百个)图像，而永远不会切换纹理。它与4K的文件大小没有任何关系(或者15年来都没有)。

而且，直到最近，纹理必须是2的幂(64,128,256)，如果你的游戏有很多奇数大小的图像，那就会浪费很多内存。将它们打包在单一纹理中可以节省大量空间。

Answer 2

这就是所谓的 -在不同的情况下有不同的理由这样做。

对于web开发，这意味着只需要一个web请求来获取图像，这可能比几个单独的请求效率高得多。这在减少单个请求的开销方面更有效率，并且最终的图像文件在总体上可能比其他情况下更小。

同样的效果可能在其他场景中可见-例如，根据文件系统的不同，存储和加载单个大图像文件可能比多个小图像文件更有效。这完全不包括在原始“总文件大小”方面获得的任何效率，而是由于每个文件的开销(目录条目、块大小等)。这有点像web场景中的“每次请求”开销，但由于因素略有不同。

Answer 3

4kb的使用率是文件在磁盘上存储方式的副作用。文件系统中最小的可寻址存储位是块，它通常是512、1024、2048等的固定大小……字节。以您的Mac为例，它使用的是4k块。这意味着即使是一个1字节的文件也需要至少4k字节的物理空间来存储，因为文件系统不可能寻址任何小于4K的存储单元。

产生这些“大”块的原因各不相同，但最大的原因是您的寻址越“细粒度”(块越小)，您在索引上浪费的空间就越多，以列出哪些块被分配给了哪些文件。如果您有1字节大小的块，那么对于存储在文件中的每个字节的数据，您还需要在文件系统的元数据中存储1+字节的使用信息，并且最终会将至少一半的存储浪费在索引上。

反之亦然-块越大，您存储的每个小于一个块大小的文件所浪费的空间就越多，所以最终取决于您愿意接受的权衡。