ETC1性能问题Android

我想支持etc1,因为它提高了性能和加载时间,但不知怎的,它比使用正常的PNG文件更糟糕。

我正在使用马里压缩工具,具有独立的RBG pkm纹理和Alpha pkm纹理。 我正在使用GLSL着色器来处理ETC1的alpha问题。 使用着色器的性能是非常糟糕的。 但即使没有着色器,只要使用RGB pkm文件(其中透明度为黑色),性能等于png。 有谁知道这个问题可能是什么?

我可以说使用ETC1或任何其他压缩将肯定会改善您的内存使用情况,但不会改善您的CPU / GPU使用情况。 查看未压缩的文件格式可以不经任何额外的处理而使用,而压缩的文件格式必须首先解压缩(处理影响)。 如果你要重复使用(而不是每次都加载),这些纹理就像其他的一样(在内存中,它们都是RGBA格式的)。

可以通过减lessGPU上的工作来改进FPS(如减less渲染的多边形数量,使用更less/更简单的着色器,使用更less的绘制调用(最重要))。 但是改变纹理的存储方式只会影响:构建大小(存储),解压缩时的GPU / CPU负载。 我可能在某些情况下是错误的,但压缩主要用于减less内存占用,并没有什么(很less)做你的FPS。

并记住孩子:早期的优化是万恶之源!

编辑1:另外请记住,使用任何种类的压缩方法并不是免费的。 节省的空间不是魔法! 你会失去质量。 你节省更多的空间 – 你将拥有更多失真的图像。 如果UI元素必须是像素完美的或包含文本,则不要使用任何types的压缩。

你的问题的答案取决于你的渲染器的瓶颈。

如果你的系统由于许多纹理读取而受到带宽限制 ,那么纹理压缩应该会有所帮助,但正如你所指出的,ETC1是不透明的,所以为了模拟透明度,你需要设置第二个纹理,R = G = B * = A *,然后在着色器中将其中一个通道复制回A.

如果OTOH,你的系统是着色器有限的 ,这可能是这种情况,额外的指令可能会让事情变得更糟。

您可能已经知道这一点,但没有渲染硬件(我知道)读取PNG文件,这些通常转换为32bpp(或16bpp)RGBA。

其他可能的select将是

  1. 识别硬件是否支持包含alpha的不同压缩纹理格式,例如。 DXTC / S3TC或PVRTC或
  2. 识别所有的纹理(或部分纹理,如果你有地图集)其中alpha == 255,明确处理它们为不透明。 无论如何这将提供额外的渲染速度的好处。