PVR textures versus PNG in OpenGL ES

Question

I\'m developing a 2D application for the iPhone that renders lots of textures. Most of them are loaded from PNG files with alpha transparency at the moment. As a test I\'ve been

Answer 1

PNGs:

• High precision color representation, not lossy
• Slower read/decompression from disk.
• Slow uploading to graphics hardware, internal pixel reordering (swizzling) is performed by drivers. Possibly, there's also conversion between RGBA<->BGRA<->ARGB, though Xcode usually converts PNGs to the color format more optimized for the hardware.
• Slower rendering because of limited memory bandwidth(more bytes to read from memory for GPU). Actual amount of slowdown depends on the usage scenario. This problem is mostly noticeable with lower than 1x magnification ratio and no MIP-mapping.
• Take more RAM/VRAM space.
• Editable, can be filtered/blended/resized/converted by your software before upload.
• Mip-maps can be generated automatically during texture upload by the drivers
• Disk space usage varies with content, very small for simple images, almost uncompressed for photorealistic ones.
• Can be exported from any image-editing software directly and quickly.

PVRs:

• Low precision lossy compression. 2 compression levels, 2 bits per pixel and 4 bits per pixel, are available. Blocky, may damage sharp edges and smooth gradients. Image quality varies with content. 3 or 4 color channels, so you can use alpha channel, but lossy compression may yield undesirable results.
• Fast loading from disk, no software decompression needed.
• Almost instant texture upload, because it's an internal hardware format, will go through drivers unchanged.
• Fast rendering because of smaller memory bandwidth usage. Pixel rendering speed is mostly limited by other factors when PVR textures are used.
• Use least amount of RAM & VRAM space.
• Mip-maps must be pre-generated.
• You can't generate or edit PVRs inside of your software AFAIK. Or it will very slow.
• Disk space usage is directly proportional to the source image sizes(fixed compression ratio). Can be further compressed (slightly) by other methods.
• Size limitations. Powers of 2, square only.
• Additional conversion tool is required, processing can be automated, but will slow down build times considerably.