feature: GIF support

[HomeArchbishop]

描述

• 支持动图包浆

  原图	15年份 + 16%画质

• 暂不支持 GIF 波普。在动图时，我隐藏了界面上的波普按钮

• 实现逻辑是「拆解」-> 「渲染」-> 「组装 GIF」

• 运行效率：上述样例完整运行三次

  1	2	3	AVER
  10302ms	10399ms	10723ms	10474ms

  我在「拆解」步骤加了手动缓存的优化，同一张 GIF 第二次渲染直接跳过「拆解」，速度提升到了 8100ms 左右。

  这是在动图只有11帧的情况下。如果一张 GIF 有上百张图片，渲染速度堪忧。这个是一个迭代，是线性的，异步也行不通。硬伤。或者是我太蠢了(/ω＼)

• 静态图片时，一个参数改变，图片会响应式渲染。如果要改多个参数，就需要等渲染很多遍。个人认为这个在 GIF 这种低效的模式下行不通。所以我在且仅在 GIF 时，取消了响应性渲染，改为手动了🥺。

  看代码可能更好理解

  watch: {
    config: {
      deep: true,
      handler (config) {
        // ...
        // 只有不是 GIF 的情况下会响应式触发
        if (!this.isGIF) {
          this._patina();
        }
      }
    },
  }

  <button v-if="isShouldRedoGIF && isGIF" @click="_patina">重新渲染GIF</button>

• 关于代码格式

  和 patina.js 一样，我创建了一个 patina-gif.js 文件，挂载了 window.patinaGIF() 到全局，专门渲染 GIF。所有的 GIF 图片将这个函数作为入口。

  这个文件完全不依赖于 patina.js 中定义的变量和函数（如 rgb2yuv, yuv2rgb 等），我对 GIF 的函数进行了一整个闭包。这样就不会定义出冲突的全局变量，扰乱正常 patina.js 的运行。

  不过这么做显然有些啰嗦。因为很多函数明明是一摸一样的（比如 Convolutes, rgb2yuv() 等）。我觉得可以模块化一下，把这些函数提出一个模块，再在 patina.js 和 patina-gif.js 里引入。不过那样就要大改原来代码的结构了，那就不能我说了算啦🤣。

待讨论

• 渲染速度，太慢啦！🤧
• 动图要支持波普吗？🧐
• 会不会出现bug？😨

就当这是一个草稿吧，个人觉得还算可以用。🥰

&& 把我加到水印里嘛（拆家大主教

[itorr]

我先做了上线的最小改动👻

关于生成时间

我觉得现在的 chiya.gif 以及常见的小表情 绿化过程体验已经很优雅了，因为有单帧的进度预览、所以并不会觉得这个过程枯燥，原本 JPEG 生成过程为了这个预览也是增加了很久的生成时间，我觉得展示生成过程也是很重要的体验。

问题主要是几秒钟以上的 gif 录屏之类，轻松就做到分钟以上的生成时间，不过我觉得这本身也不是适合 gif 存储的信息，可能需要在遇到多帧数动图时 增加一步交互 提醒确认一下再触发生成之类的

代码格式

这个问题好苦恼OAQ 现在除了很多共有逻辑之外 甚至界面都混在了一起（ 是我多个环节偷懒导致的，dbq(ಥ_ಥ)
确实需要把简单函数抽象出来，引入个合适的模块化方案🤔

动图波普

😱动图波普听起来就很带感，如果按照原图尺寸切块来做 确实感觉也可行（

bug？什么 bug、那都是 issue 😍

（快再多加些水印名www

[HomeArchbishop]

好耶！(✧∇✧)