博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
iOS第三方做滤镜最主流的开源框架GPUImage
阅读量:4329 次
发布时间:2019-06-06

本文共 995 字,大约阅读时间需要 3 分钟。

GPUImage是现在iOS做滤镜最主流的开源框架。作者BradLarson基于openGL对图片处理单元进行封装,提供出GPUImageFilter基类,配合shader,常用滤镜都拿下不是问题。  GPUImage中的有几个概念:

⁃ output,输出源

⁃ intput,输入源

⁃ filter,滤镜

所以一个完整的滤镜处理流程是: output+X+input,X就是滤镜组(1+个滤镜)。GPUImage为了方便,新版本中提供了GPUImageFilterPipeline 这个东西,方便用户使用多个滤镜组合,不用担心前后的链式逻辑。

GPUImage将图片滤镜处理和动态滤镜分开了,动态滤镜是按照上面那个流程,但图片处理却是以(output+filter)*X + input这种逻辑。如果处理一张图片的效果需要用到多个滤镜组合,用一个滤镜生成一张图片output,然后传给下一个滤镜处理,这个过程中如果滤镜叠加次数比较多,或者这个滤镜效果被调用多次,这样消耗的内存是特别大的,每个滤镜处理后导出的图片output都存在内存中,如果原图特别大,估计内存要爆了。

如果都是以output+X+input这种模式来处理的,这样代码逻辑单一,效率高,吃内存也没那么多。看了源码知道output +X+ input ,当X为多个时,上个滤镜n处理得到的纹理,还存在GPU显存中,GPU直接将这张纹理传给了n+1作为其output,这样整个滤镜流程下来,只有一张纹理内存的占用。

以这条线来走,过程中基本就没遇到什么问题,只是代码结构设计和封装耗时。项目里,发现滤镜模块调用完了以后,内存上去了下不来,反复检查,所有GPUImage相关元素都已经释放了。后来想到了显存,arc环境下,只负责回收oc对象的内存,显存自然需要GPUImage使用者自己来回收,这样也就容易了,翻GPUImage的api,知道

GPUImageContext中有个framebufferCache:

 

[[GPUImageContextsharedImageProcessingContext].framebufferCachepurgeAllUnassignedFramebuffers]。

 

 

 

转载于:https://www.cnblogs.com/canghaixiaoyuer/p/4713021.html

你可能感兴趣的文章
响应式web设计之CSS3 Media Queries
查看>>
实验三
查看>>
机器码和字节码
查看>>
环形菜单的实现
查看>>
【解决Chrome浏览器和IE浏览器上传附件兼容的问题 -- Chrome关闭flash后,uploadify插件不可用的解决办法】...
查看>>
34 帧动画
查看>>
二次剩余及欧拉准则
查看>>
Centos 7 Mysql 最大连接数超了问题解决
查看>>
thymeleaf 自定义标签
查看>>
关于WordCount的作业
查看>>
C6748和音频ADC连接时候的TDM以及I2S格式问题
查看>>
UIView的layoutSubviews,initWithFrame,initWithCoder方法
查看>>
STM32+IAP方案 实现网络升级应用固件
查看>>
用74HC165读8个按键状态
查看>>
jpg转bmp(使用libjpeg)
查看>>
linear-gradient常用实现效果
查看>>
sql语言的一大类 DML 数据的操纵语言
查看>>
VMware黑屏解决方法
查看>>
JS中各种跳转解析
查看>>
JAVA 基础 / 第八课:面向对象 / JAVA类的方法与实例方法
查看>>