问题描述
我正在为iPhone开发一个渲染大量纹理的2D应用程序。它们中的大多数都是从具有Alpha透明度的PNG文件加载的。作为一个测试，我一直在玩PVR测试，看看是否有任何性能差异。
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.
PNG纹理加载了Texture2D类，来自崩溃着陆的例子。 PVR测试使用PVRTextureLoader示例中的PVRTexture类加载。我使用Apple的texturetool创建PVR纹理。
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.
作为测试我渲染背景（512 * 512）并在36个90 * 64像素精灵之上（来自a 512 * 512纹理）具有透明度。 PVR纹理渲染大约58 fps，PNG渲染47 fps。这是我可以期待的还是差异会更大？另外，texturetool生成的纹理看起来真的很糟糕，PVRTexTool更好吗？
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?
推荐答案
PNGs：
- 高精度颜色表示，无损耗
- 从磁盘读取/解压缩较慢。
- 慢速上传到图形硬件，内部像素重新排序（混合）由驱动程序执行。可能还有RGBA< - > BGRA< - > ARGB之间的转换，尽管Xcode通常将PNG转换为针对硬件更优化的颜色格式。
- 由于内存带宽有限，渲染速度较慢（从GPU的内存中读取更多字节）。实际减速量取决于使用情况。这个问题在低于1倍的放大率和没有MIP映射时非常明显。
- 占用更多RAM / VRAM空间。
- 可编辑，可以在上传之前通过您的软件过滤/混合/调整大小/转换。
- 在纹理上传期间，驱动程序可以自动生成Mip-maps
- 磁盘空间使用方式因内容而异，对于简单的图像而言非常小，对于逼真的图像几乎没有压缩。
- 可以直接快速地从任何图像编辑软件导出。
- 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.
- 低精度有损压缩。可提供2个压缩级别，每像素2位和每像素4位。块状，可能会损坏锋利的边缘和平滑的渐变。图像质量因内容而异。 3或4个颜色通道，因此您可以使用alpha通道，但有损压缩可能会产生不良结果。
- 从磁盘快速加载，无需软件解压缩。
- 几乎即时纹理上传，因为它是内部硬件格式，将通过驱动程序保持不变。
- 快速渲染，因为内存带宽使用量较小。当使用PVR纹理时，像素渲染速度主要受到其他因素的限制。
- 使用最少量的RAM& VRAM空间。
- 必须预先生成Mip-maps。
- 您无法在软件AFAIK中生成或编辑PVR。或者它会非常慢。
- 磁盘空间使用量与源图像大小（固定压缩比）成正比。可以通过其他方法进一步压缩（略）。
- 大小限制。 2的功率，只有方形。
- 需要额外的转换工具，处理可以自动化，但会大大减慢构建时间。
- 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.
PNGs:
这篇关于PVR纹理与OpenGL ES中的PNG的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！