• iOS第三方做滤镜最主流的开源框架GPUImage


    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]。

     

     
  • 相关阅读:
    固定表头的table
    Object.assign()方法
    一个命令解决linux重启nginx就丢失pid文件问题
    js-xlsx 一个实用的js 导出列表插件
    SparkSQL执行时参数优化
    HSQL转化为MR过程
    简单写下提交sql-map-shuffle-reduce的过程
    order by/sort by/distribute by /cluster by 的区分
    hive中如何控制mapper的数量
    hive 窗口和分析函数功能
  • 原文地址:https://www.cnblogs.com/canghaixiaoyuer/p/4713021.html
Copyright © 2020-2023  润新知