使用OpenGL ES纹理caching而不是glReadPixels来获取纹理数据
在iOS 5中，引入了OpenGL ES纹理caching，以提供从摄像机video数据到OpenGL的直接方式，而无需复制缓冲区。 在会话414 – WWDC 2011的OpenGL ES for iOS 5中进行了纹理caching的简要介绍。
我发现了一篇有趣的文章 ，最后进一步滥用了这个概念，并且通过简单地locking纹理，然后直接访问缓冲区来绕过对glReadPixels的调用。
由于iPad 2中使用的基于图块的渲染器（即使只使用1×1纹理）， glReadPixels的速度非常慢。 但是，所描述的方法似乎处理比glReadPixels更快。
文章中提出的方法是否有效，是否可以用来提升依赖glReadPixels应用程序？
由于OpenGL处理与CPU并行的graphics数据， CVPixelBufferLockBaseAddress调用如何知道什么时候渲染完成而不与OpenGL交谈？
基于上面链接的文章和WWDC 2011的苹果的ChromaKey样本，我在这个答案中描述了一个这样做的方法。鉴于苹果在其中的一个样本中使用了这一点，而且我还没有听到任何反对OpenGL ES工程师，我相信这是纹理caching的有效使用。 它适用于我已经尝试的每个iOS 5.x兼容设备，并且也适用于iOS 5.0和5.1。 它比glReadPixels()快得多。
至于何时locking像素缓冲区的基地址，你应该能够使用glFlush()或类似的东西阻塞，直到所有的数据已经呈现给你的FBO纹理。 这似乎适用于我从纹理支持的FBO完成的30 FPS 1080p电影编码。