GPUImage结构及细节分析

GPUImage 专注于使用基于openGLES2.0的GPU加速来处理图像，相机图像流及视频，框架中大致的类分布如图

GPUImage框架 类结构图.png

GPUImage使用的一些技术

快速上传texture

在Capturing from the Camera using AV Foundation on iOS 5 中的ChromaKey(Bridging CoreVideo and OpenGLES)部分，其目的旨在开发者可以加快处理速度且更好地使用GPU，添加了新的API CVOpenGLESTextureCache，这个Core Foundation类的目的旨在桥接CVPixelBuffer与OpenGLES Texture，而其主要的思想是避免CPU到GPU之间来回的复制（就拿720P的BGRA数据来说，要将它传入并传出GPU意味着需要做每秒220MB的拷贝更别说还要将数据来回传输，按bradson在stackoverflow中的说法，640*480的texture上传到GPU的数据为9ms的话，220MB/s的拷贝速度是一个较为可信的瓶颈速度）及进行texture的复用（创建新的texture时需要维护的数据），这些api都定义在中
高效地将pixelBuffer映射为texture的方法:

CVOpenGLESTextureCacheCreateTextureFromImage(
kCFAllocatorDefault,
textureCache, //openGLESTextureCacheRef
pixelBuffer,
NULL, //optional texture attributes
GL_TEXTURE_2D, //the target,唯二的选择是GL_RENDERBUFFER
GL_RGBA, //internal format
width,
height,
GL_RGBA, //pixel format
GL_UNSIGNED_BYTE, //data type of the pixels
0, //plane index to map(BGRA has only one plane)
&outTexture);

CVOpenGLES Texture绑定

同样是在2011 wwdc 的session 419, 新的texture绑定概念也诞生了。众所周知，正常的绑定texture的操作一般是先用glGenTexture生成texture，再获取CVPixelBufferGetBaseAddress(pixelbuffer)，然后用glTexImage2D(....)将pixeldata作为最后一个参数传进去，这时在底层发生的事情其实相当于用memcpy()复制了这份数据并传到Texture Image中供Texture Object使用，如下图：

�标准texture绑定.png

而cvopengles texture绑定避免了memcpy而直接将pixelbuffer与Texture Image绑定，同时使用api时，也不再传pixelbuffer中图像的裸指针，而是直接传入CVPixelBufferRef，同时获取生成的texture

CVOpenGLES Texture绑定.png

openGL命令在CPU与GPU之间的同步

在执行openGL的绘制命令之后，很自然地就会想，如果这时候马上去读framebuffer中的图像会是已经绘制完成的样子吗？glDrawArrays或者glDrawElements命令本身是同步的吗？如stackoverflow上所说，openGL标准定义了"as if"原则，即在执行openGL命令时，假装之前的所有opengl命令已经同步执行完了，因为在需要同步以确保"as if"原则的时候，openGL实现需要确保进行同步。比如多个绘制命令之后，这些命令本身很大可能是异步的，但如果此时需要调用glReadPixels等，则glReadPixels会block并等待之前所有的绘制命令执行结束再读取并将内容存储到用户内存中。所有原则即是openGL会尽可能地延迟进行阻塞操作，当然，除非你需要显式同步Sync objects 。

toll bridge 与 内存管理

在使用Avfoundation api的时候需要用到大量的CF对象比如cfdictionary等，通常在将本地OC对象转成CF对象之后，如果没有本地显式释放，总感觉会有内存泄漏的风险。这时候就需要重温一下toll bridge转换的语义了如develop document中所述：

编译器并不会自动管理CF对象的生命周期，程序员需要显式地通过中的cast语法，或者NSObject.h中定义的Core Foundation宏对CF对象ownership进行操作
1.__bridge在OC与Core Foundation之间传递指针，但并不进行所属权的转移
2.__bridge_retained或者CFBridgingRetain将OC指针转换为CF指针并将所属权转移给程序员，需要手动CFRelease
3.__bridge_transfer或者CFBridgingRelease将非OC指针转换为OC指针并将所属权转移给ARC，ARC对对象生命期负责

所以如果ARC中创建的OC对象通过__bridge转换为CF对象传入CF的API并不需要手动释放