普通に組むとエンコードもデコードも遅いくせに1コアしか動いていない状態になる。作者も「アルゴリズム上マルチスレッド化しても意味ないんだよねー、どうせ複数画像を同時にデコードとかするでしょ?それで演算リソースは埋めたらいいんじゃない?」とか言ってて、ふーん、まあいいけど、とマルチスレッドで複数画像デコードを実装してみると、出力画像が壊れていて、まずここでため息が一つ漏れる。GithubのIssueを検索したら既に突っ込まれてて、それに対する作者の返答が「ああ、グローバル変数が残ってるからじゃないかな。動作させることには成功させて(保守性とか無視で小汚く改変したのでプルリクとかは出しませんよ)、やっとちゃんとした絵は出るようになったけど、それでもまだiPad上でまともに操作できる速度は出ていなくて、ならば、デコードしたい1枚の画像を何枚かに分割してエンコードしておいて、それぞれをマルチスレッドで一気にデコードすればサクサクになるんじゃないかって思いついて、エンコーダ/デコーダを画像分割して扱えるように仕様を拡張し終えたのが今。自作の書籍ビューワでは、webpを使って一冊の本を丸々ページ送り全力で表示させようとすると(もちろんページ数とかに依存するけど一般的に)1秒掛からないくらいで終わるくらい軽いのだけれども、FLIFはここまで最適化を詰めても、おおよそ数十秒掛かる。単純計算で2桁くらい重たい。それでも、パラパラ普通にページを送る程度なら引っかかりを感じることはなくなったので、かろうじて実用レベルには達したと考えてよさそう。努力は無駄にならずに済んだ。首の皮一枚ってところなので、今後のプロセッサ能力の向上にも頼らないといけないけど。FLIFの比較で、16階調のグレスケ画像で平均して25%ほど小さくなった。デコーダ側はまあなんとかなった、問題はエンコーダ側だ。webpのエンコーダに比べてだいたい4-5倍くらい遅い。1冊2分で終わっていたエンコードが10分弱とか掛かる。エンコードはそう何度もすることじゃないから速度は度外視、と今までは考えていたけど限界が来てしまった。flif_encoder_encode_memory()の中で9割以上の処理負荷が掛かってるから、(ライブラリに手を入れる以外)最適化のしようがない。今のメインPCが6700Kなので、最近のもっと多コアなCPUに変えればコア数分だけ速くなってくれるだろうと軽く考えちゃっていいのかなー。