iphone - Texturas PVR versus PNG en OpenGL ES

opengl-es (2)

Estoy desarrollando una aplicación 2D para el iPhone que rinde muchas texturas. La mayoría de ellos se cargan desde archivos PNG con transparencia alfa en este momento. Como prueba, he estado jugando con PVR-testures también para ver si hay alguna diferencia de rendimiento.

Las texturas PNG se cargan con la clase Texture2D que viene con el ejemplo de aterrizaje forzoso. Las pruebas PVR se cargan con la clase PVRTexture del ejemplo PVRTextureLoader. Creo las texturas PVR usando la herramienta de textura de Apple.

Como prueba, renderizo un fondo (512 * 512) y encima de esos 36 sprints de 90 * 64 píxeles (desde una textura 512 * 512) con transparencia. Las texturas PVR se renderizan a alrededor de 58 fps y el PNG a 47 fps. ¿Es esto lo que puedo esperar o la diferencia debería ser mayor? Además, las texturas generadas por texturetool se ven realmente mal, ¿es mejor PVRTexTool?

El rendimiento debería ser mejor con las texturas PVRTC, ya que están comprimidas (con pérdida). La descompresión se realiza en el hardware de gráficos en sí. Se están transfiriendo menos datos de textura, por lo que obtienes más ancho de banda. El precio que paga por la RAM y el ahorro de ancho de banda es la pérdida de calidad.

PNG:

Representación de color de alta precisión, no con pérdida
Lectura / descompresión más lenta del disco.
Subida lenta al hardware de gráficos, el reordenamiento interno de píxeles (swizzling) es realizado por los controladores. Posiblemente, también hay conversión entre RGBA <-> BGRA <-> ARGB, aunque Xcode generalmente convierte PNG al formato de color más optimizado para el hardware.
Retraso más lento debido al ancho de banda de memoria limitado (más bytes para leer desde la memoria para GPU). La cantidad real de desaceleración depende del escenario de uso. Este problema se nota principalmente con una relación de aumento inferior a 1x y sin mapeo MIP.
Tome más espacio RAM / VRAM.
Editable, puede ser filtrado / mezclado / redimensionado / convertido por su software antes de cargarlo.
Mip-maps se pueden generar automáticamente durante la carga de textura por los controladores
El uso de espacio en disco varía con el contenido, muy pequeño para imágenes simples, casi sin comprimir para fotorrealistas.
Se puede exportar desde cualquier software de edición de imágenes directa y rápidamente.

PVRs:

Compresión con pérdida de baja precisión. 2 niveles de compresión, 2 bits por píxel y 4 bits por píxel, están disponibles. Blocky, puede dañar bordes filosos y degradados suaves. La calidad de la imagen varía con el contenido. 3 o 4 canales de color, por lo que puede utilizar el canal alfa, pero la compresión con pérdidas puede producir resultados no deseados.
Carga rápida desde el disco, no se necesita descompresión de software.
La carga de textura casi instantánea, debido a que es un formato de hardware interno, pasará por los controladores sin cambios.
Renderizado rápido debido al menor uso de ancho de banda de memoria. La velocidad de reproducción de píxeles está generalmente limitada por otros factores cuando se utilizan texturas PVR.
Use la menor cantidad de espacio RAM y VRAM.
Mip-maps debe pregenerarse.
No puede generar ni editar PVR dentro de su software AFAIK. O será muy lento.
El uso de espacio en disco es directamente proporcional a los tamaños de imagen de origen (relación de compresión fija). Se puede comprimir aún más (levemente) con otros métodos.
Limitaciones de tamaño Potencias de 2, solo cuadrado.
Se requiere una herramienta de conversión adicional, el procesamiento puede ser automático, pero ralentizará considerablemente los tiempos de construcción.