我们的产品包含一种软件图像解码器，它本质上会生成需要快速复制到屏幕的全帧像素数据(我们在 iOS 上运行)。
目前我们正在使用 CGBitmapContextCreate，我们直接访问内存缓冲区，然后对于每一帧我们调用 CGBitmapContextCreateImage，然后将该位图绘制到屏幕上。这对于在 iPad 的视网膜显示屏上以不错的帧速率进行全屏刷新来说太慢了(但对于非 Retina 设备来说还可以)。
我们已经尝试了各种基于 OpenGL ES 的方法，包括使用 glTexImage2D 和 glTexSubImage2D(本质上是渲染到纹理)，但 CPU 使用率仍然很高，我们无法获得超过 ~30 FPS 的完整-iPad 3 上的屏幕刷新。问题是在 30 FPS 的情况下，CPU 使用率几乎为 %100，仅用于将像素复制到屏幕上，这意味着我们在 CPU 上进行自己的渲染没有太多工作要做.
我们愿意使用 OpenGL 或任何可以为我们提供最佳性能的 iOS API。像素数据被格式化为每像素 32 位的 RGBA 数据，但我们有一些灵 active ......
有什么建议吗？
因此，坏消息是您遇到了一个非常棘手的问题。我已经在这个特定领域进行了大量研究，目前，您实际上可以在 2x 下对全屏大小的帧缓冲区进行 blit 的唯一方法是使用 h.264 解码器。一旦您将图像数据解码到实际内存中(查看 GPUImage)，就可以使用 OpenGL 完成很多不错的技巧。但是，最大的问题不是如何将像素从实时内存移动到屏幕上。真正的问题是如何将像素从磁盘上的编码形式移动到实时内存中。可以使用文件映射内存将像素保存在磁盘上，但 IO 子系统的速度不够快，无法交换足够多的页面以从映射内存流式传输 2 倍全屏大小的图像。这曾经在 1 倍全屏尺寸下工作得很好，但现在 2 倍尺寸的屏幕实际上是 4 倍的内存量，硬件跟不上。您还可以尝试以更压缩的格式(如 PNG)将帧存储在磁盘上。但是，然后解码压缩格式将问题从 IO 绑定(bind)更改为 CPU 绑定(bind)，您仍然卡住了。请查看我的博客文章 opengl_write_texture_cache，了解我使用该方法找到的完整源代码和计时结果。如果您有一个非常特定的格式，您可以将输入图像数据限制为(如 8 位表)，那么您可以使用 GPU 通过着色器将 8 位数据作为 32BPP 像素进行 blit，如本示例 xcode 项目 opengl_color_cycle 所示.但是，我的建议是看看如何使用 h.264 解码器，因为它实际上能够在硬件中解码这么多数据，并且没有其他方法可能会给您提供您正在寻找的结果。
关于ios - 在 iOS 中将 RGB 像素数据高性能复制到屏幕，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11423853/
| 欢迎光临 OGeek|极客世界-中国程序员成长平台 (http://sqlite.in/) | Powered by Discuz! X3.4 |