21

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 playing around with PVR-testures as well to see if there is any performance difference.

The PNG-textures are loaded with the Texture2D class that came with the crash landing example. The PVR-testures are loaded with the PVRTexture class from the PVRTextureLoader example. I create the PVR textures using Apple's texturetool.

As a test I render a background (512*512) and on top of that 36 90*64 pixel sprites (from a 512*512 texture) with transparency. PVR textures renders at around 58 fps and the PNG at 47 fps. Is this what I can expect or should the difference be bigger? Also, the textures generated by texturetool looks really bad, is the PVRTexTool better?

deft_code
  • 57,255
  • 29
  • 141
  • 224
Jens Utbult
  • 923
  • 1
  • 7
  • 16

2 Answers2

44

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.
noop
  • 320
  • 4
  • 9
  • I used PVR as a container that holds PNG image inside. This way I can break square only limitation. If I don't use PVR as a selected format of image, but just a container, do I get the benefit of PVR after all? – haxpor Apr 06 '13 at 16:46
  • 1
    To be clear (because it seems surprising, and it's not entirely clear above): PVR's take less memory on the GPU, as well as on the CPU. Using PVR compression *not only* gets you better startup time and better render performance - it also allows you to load more textures of larger size simultaneously. – Adam Aug 24 '13 at 12:37
  • _"Low precision lossy compression (2 levels ), blocky, no sharp edges and smooth gradients."_ 2 Levels? I don't know what you mean by that. Also you can have sharp edges and smooth gradients, but it will depend on how much other detail needs to be represented in each local neighbourhood. – Simon F Nov 12 '15 at 14:54
  • @Adam I said that PVRs take less RAM _and_ VRAM space. It should be obvious that is something takes less space, more can be loaded. – noop Jan 12 '16 at 13:08
  • @SimonF "don't know what you mean by that" - Two compression levels. 4bpp and 2 bpp. "Also you can have sharp edges and smooth gradients" In general case, PVR causes noticeable amount of blurring and banding. Yes, depends on source material, but I didn't plan to write a book about it. The answer is already long enough. – noop Jan 12 '16 at 13:15
  • 1
    Ok. fair enough, though [YMMV](https://computergraphics.stackexchange.com/questions/1523/how-does-hardware-texture-compression-work/1551#1551) (which was my attempt at a book ;-) ) FWIW, the PVRTC 'square only' limitation is a software restriction imposed in iOS. AFAIK it's not, for example, in Android PowerVR devices. – Simon F Jan 12 '16 at 16:20
  • I said it was unclear. You used a single letter, in a secondary word, buried in a phrase ... for what IMHO is the 1st or 2nd most important point about PVR. Also, of course - VRAM doesn't exist on most devices using PVR today :) (which, again, was something of a big surprise to me) – Adam Jan 13 '16 at 16:32
10

Performance should be better with the PVRTC textures, as they are compressed (lossy). The decompression is done in the graphics hardware itself. Less texture data is being transferred around, so you get more bandwidth. The price you pay for the RAM and bandwidth saving is the loss of quality.