1.8.0.0

[github-actions[bot]]

We're announcing the release of the 1.8.0.0.

Differences from version 1.7.x.x:
Migrated to Imagedecoder(native) backend
More performance optimizations?(maybe :) )

Note that this version only supports Android S and above since it depends on new Imagedecoder(NDK native) backend

@txyyh will continue to maintain 1.7.x.x branch

---

我们在此宣布 1.8.0.0 版本的发布 🎉

这与 1.7.x.x 版本的区别：
切换到了 Imagedecoder(native) 后端
也许会有更好的性能表现（吧（（

另外注意，由于依赖新的 Imagedecoder(NDK native) 后端，此版本只能安装于 Android 12 及以上的系统 (≧﹏ ≦)

@txyyh 将会继续pick维护 1.7.x.x 分支

---

This discussion was created from the release 1.8.0.0.

[VoidxHoshi]

imagedecoder为什么使用ndk的api而不是Java/kotlin的api呢？（这样不是更好维护吗？）
图片加载框架的话，貌似coil比原生imagedecoder要更好一些，在看上去有转为kotlin项目的想法的情况下。

[asuka-mio]

首先关于第一个问题，使用 Java 的ImageDecoder API 需要重构 app 现有的渲染系统
因为，EhViewer 是用 OpenGL 渲染的，然而 Java 那边的 ImageDecoder API 只能解码成 Bitmap 或者别的什么，需要再把 pixel 抠到 raw buffer。这样就会有效率问题
而 ndk 的 API，解码出来直接就是 raw pixel

[asuka-mio]

关于第二个问题，
虽然 coil 在高版本系统用的也是 ImageDecoder API，但在低版本系统上，coil 使用的是自带实现
因此，我们仍需把解码库打包进应用，这样就起不到精简的作用
而且 coil 本身的性能和内存管理也得斟酌一下

[asuka-mio]

至于为何不重构渲染系统，从 OpenGL 为基础的图片渲染转到 Bitmap 为基础
首先，我并不能确保重构后会有更好的资源占用和性能表现；不如说，效率上的降低是更有可能的
而且，项目可维护性并不会在重构后有很大的提升
所以目前渲染系统没什么重构的必要

[VoidxHoshi]

谢谢解答

[VoidxHoshi]

well
原版渲染方式实现基于OpenGL ES 1.1或2.0
有迁移至OpenGL ES 3.2的想法吗？

[asuka-mio]

gles3.2有什么特别beneficial的特性吗，如果没有的话，换不换都一样吧
而且对于这么个单纯只是2d加载图片的应用，那些特性基本上都没啥用

倒是可以考虑一下vulkan
因为vulkan里面buffer是可以共享的，很多地方都可以实现zero copy技术了