文章目录
前言
上篇文章（见 ESP32-S3 + Arduino 各种 JPEG 解码库速度对比，到底哪个才是最快的？）测试了三个 JPEG 解码库的性能，最终结论是 ESP_NEW_JPEG 在低分辨率遥遥领先，但到了 240x240 和 320x240，被 JPEGDEC 追平。
结果最近想测试 ESP_NEW_JPEG 的 block 解码方式，发现怎么找都找不到对应的 API，这才意识到——我用的库版本根本不对 😅。
问题出在哪里
上篇文章用的是 Arduino 生态里的封装库 ESP32_JPEG，这个库最后一次更新是三年前，是对 ESP_JPEG 早期版本的封装，早就停止维护了。
乐鑫官方真正在维护的最新版本是另一个仓库：esp-adf-libs/esp_new_jpeg，五个月前还在更新，block 解码、最新的 SIMD 优化都在这里。
两个库同名，但版本差距已经是三年了，之前完全踩坑了 😂。
更新库，重新测试
换成最新版 ESP_NEW_JPEG，测试环境与上次完全一致：
- ESP32-S3-Zero，240MHz 双核
- 测试图片：Lenna，160x80 / 240x240 / 320x240，质量 80
- 每个尺寸解码 10 次取平均
160x80 解码速度
| Library | Decode(ms) | Draw(ms) | Total(ms) | FPS |
|---|---|---|---|---|
| Tjpg_Decoder | 10.74 | 11.48 | 22.23 | 45.0 |
| JPEGDEC | 7.42 | 6.91 | 14.33 | 69.8 |
| ESP32_JPEG | 3.75 | 6.17 | 9.93 | 100.8 |
240x240 解码速度
| Library | Decode(ms) | Draw(ms) | Total(ms) | FPS |
|---|---|---|---|---|
| Tjpg_Decoder | 43.85 | 51.13 | 94.98 | 10.5 |
| JPEGDEC | 28.91 | 28.10 | 57.01 | 17.5 |
| ESP32_JPEG | 17.44 | 30.48 | 47.92 | 20.9 |
320x240 解码速度
| Library | Decode(ms) | Draw(ms) | Total(ms) | FPS |
|---|---|---|---|---|
| Tjpg_Decoder | 57.63 | 68.10 | 125.73 | 8.0 |
| JPEGDEC | 38.12 | 38.21 | 76.33 | 13.1 |
| ESP32_JPEG | 23.99 | 39.60 | 63.59 | 15.7 |
勘误结论
旧版测试中，240x240 和 320x240 分辨率下 JPEGDEC 几乎追平 ESP_NEW_JPEG，这个结论是错的。
更新到最新版后，ESP_NEW_JPEG 在所有分辨率下都是三个库里最快的，差距相当明显：
- 160x80：ESP_NEW_JPEG 9.93ms / 100.8 FPS，JPEGDEC 14.33ms，领先 30%
- 240x240：ESP_NEW_JPEG 47.92ms / 20.9 FPS，JPEGDEC 57.01ms，领先 16%
- 320x240：ESP_NEW_JPEG 63.59ms / 15.7 FPS，JPEGDEC 76.33ms，领先 17%
更新后的选库建议：
- 追求最快解码速度 → 用 ESP_NEW_JPEG（最新版），硬件加速 + SIMD，全分辨率最强
- 需要简单好用、兼容 TFT_eSPI → 用 JPEGDEC，SIMD 加速后性能也不差
- 需要 Progressive JPEG 支持 → 只能用 JPEGDEC 或 Tjpg_Decoder，ESP_NEW_JPEG 不支持
上篇文章也已经同步更新了测试数据和结论。
后记
如果不是想测 block 解码，可能就这么一直用着三年前的旧版本了……以后用 Arduino 封装库之前，还是要确认一下源头仓库是不是真正在维护的那个 😔。
block 解码的测试结果后面再单独写一篇。
0 条评论。