Quartz 如何处理纹理压缩？
我正在 iPhone 上进行开发，我们的大部分游戏都使用 OpenGL ES，但也有一些菜单使用 CGImage 和 Quartz 来显示。 在OpenGL ES中，我知道无论采用什么图像压缩（JPG、PNG等），作为纹理存储在内存中的数据都是8位纹理，除非我使用PVRTC，在这种情况下我可以得到它2 或 4 位。 由于大型 CGImage，我们一直遇到内存问题，所以我的问题是……Quartz 和 CGImage 使用什么样的优化和压缩？ 我在 Apple 的文档中找不到详细信息，而我真的想知道放入 256 色图像或 JPG 与 PNG 是否会有所不同，如果尺寸为 2 的幂有帮助的话，等等。速度并不重要，内存才是瓶颈。
谢谢。
I'm developing on the iPhone and the majority of our game is using OpenGL ES, but there are also menus that use CGImage and Quartz in order to be displayed. In OpenGL ES, I know that no matter what image compression goes in (JPG, PNG, etc.), the data stored in memory as a texture is an 8-bit texture, unless I use PVRTC in which case I can get it to 2 or 4 bits. We've been having memory issues due to large CGImages, so my question is... what sort of optimizations and compressions do Quartz and CGImage use? I can't find the details in Apple's docs, when really I want to know if it would make a difference to put a 256-color image in, or a JPG vs a PNG, if having the dimensions at a power of 2 help, etc. Speed is unimportant, memory is the bottleneck here.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
石英是未压缩的。 它用于快速合成和渲染像素精确的内容。 一旦你的图像被绘制到上下文中，它们来自哪里并不重要，它们会获取该上下文每个像素所占用的任何像素，无论它们有多少个像素（如果我没记错的话，设备中通常每个像素 4 个字节）。 它所做的一件大事是预乘 Alpha 以避免混合。
现在，一些在内存压力下的视图可以驱逐其内容（如果未显示），并根据需要重新构建它们。 在这些情况下，来自压缩源的 CGImage 通常最终会占用更少的内存，但我怀疑这与您描述的情况无关。
Quartz is uncompressed. It is for quickly compositing and rendering pixel accurate content. Once your images have been drawn into a context it doesn't matter where they came from, they take whatever that context takes per pixel for however many pixels they have (generally 4 bytes per pixel in a device if I recall correctly). The one big thing it does is premultiplies the alpha to avoid blending.
Now, some views under memory pressure can evict their contents if not displayed, and reconstitute them as needed. In those cases a CGImage from a compressed source generally ends up taking less memory, but I suspect that is not relevant in the case you described.