ESP32-S3 屏幕显示图片格式对显示速度的影响 png rgb565针对 CardputerESP32-S3 SPI RGB565 屏固件中的图标绘制。相对耗时为经验量级非精确 benchmark同尺寸对比以RGB565 已在 RAM、pushImage为1×。1. 结论先看同尺寸下常见路径大致是RGB565 直推 ≫ ARGB8888 Alpha 混合 ≫ 每次现场解 PNG优先级做法适用要最快预生成RGB565透明烤进黑底→pushImage底色固定为黑的 UI 图标要透明叠任意底预生成ARGB8888→pushAlphaImage需要半透明/抗锯齿叠在多变底色上要省 Flash、改图方便保留PNG首次解码后RAM 缓存数量少、可接受首次卡顿不推荐反复每次drawPngFile列表翻页、按键闪烁等高频重绘面板最终都是RGB565ARGB8888 / PNG 都会在上屏前变成 16-bit。2. 各路径实际在做什么2.1 PNGdrawPngFileLittleFS 读文件 → zlib 解压 → PNG filter 还原 → 颜色/透明处理 → 写屏慢主要慢在CPU 解码zlib filter不是 30×30 像素本身。有 Alpha 时由 M5GFX/LovyanGFX 做混合画质通常最好、也最省 Flash。每次重绘都走全流程就会明显卡空调模式切换、米家列表等。2.2 预生成 RGB565.rgb565LittleFS 读原始像素 → pushImage直接写屏无 zlib、无 Alpha 混合Flash / SPI 约为 ARGB 的一半。不支持透明通道透明区需提前合成到固定底色本项目 UI 多为黑底。手写转换若处理 Alpha/抗锯齿不当观感会明显差于库解码 PNG应用「与屏上一致」的像素例如库解码后再落盘画质才可靠。2.3 预生成 ARGB8888.argb8888LittleFS 读原始像素 → pushAlphaImage读底色 混合 写回跳过 zlib保留完整 Alpha。字节序需与lgfx::argb8888_t一致B, G, R, A见scripts/png_to_rgba8888.py。比 RGB565 慢主要因为逐像素 Alpha其次是 4 字节/像素的读写量。2.4 PNG 解码一次 RAM 缓存首次drawPngFile → readRect 存 RGB565 之后pushImage画质对齐库解码重绘接近 RGB565 直推。占 RAM宽 × 高 × 2 × 槽位数空调 8 张 30×30 ≈ 14 KB。3. 相对耗时同分辨率路径相对耗时说明RGB565 已在 RAM →pushImage1×最快RGB565 从 Flash →pushImage约 1.5–3×多 FS 读ARGB8888 已在 RAM →pushAlphaImage约 3–6×Alpha 混合ARGB8888 从 Flash →pushAlphaImage约 4–8×FS AlphaPNG 每次drawPngFile约 10–40×zlib 解码波动大绝对量级体感参考30×30路径大约RGB565pushImageRAM 1 msARGB8888pushAlphaImageRAM约 2–5 msPNG 现场解码约 10–30 ms70×70大约再乘5–6 倍按面积。若整页还有清屏、大量文字、布局计算图标优化后「体感不明显」是正常的——瓶颈可能不在图标。4. Flash / RAM 占用同图公式无压缩原始像素RGB565宽 × 高 × 2ARGB8888宽 × 高 × 4PNG视压缩而定通常远小于原始像素尺寸RGB565ARGB888825×25≈ 1.25 KB≈ 2.5 KB30×30≈ 1.8 KB≈ 3.6 KB60×60≈ 7.2 KB≈ 14.4 KB70×70≈ 9.8 KB≈ 19.6 KB本仓库 LittleFS 分区约1.5 MBdefault_8MB.csv的 spiffs。设备图标全套 ARGB 约数百 KB 量级空间一般够用若同时保留 PNG ARGB体积会叠加上去。RAM 策略少量固定图标如空调 8 张可常驻缓存。大量设备图标用暂存缓冲按需从 Flash 读不全量常驻避免上百 KB数 MB RAM。5. 本项目现状实现要点资源格式优先绘制入口空调模式/icon/ir/.argb8888回退 PNGsrc/app_ir.cpp可带槽位缓存设备图标/icon/device/.argb8888回退 PNGsrc/app_device_icons.cppscratch 按需加载Logo/logo_60.argb8888回退 PNGdrawAppLogo60Icons 应用中的设备图同上走drawDevicePngNativesrc/app_icon_demo.cpp箭头 / WiFi / 电池等矢量代码绘制src/app_icons.cpp无图片文件转换脚本python scripts/png_to_rgba8888.py data/icon/ir python scripts/png_to_rgba8888.py data/icon/device data/logo_60.png data/logo_50.png另有历史脚本scripts/png_to_rgb565.py透明合成到黑底若改回 RGB565 路线需保证转换质量后再替换绘制路径。网页配置预览仍使用PNG浏览器友好固件绘制优先原始像素文件。6. 选型建议黑底 UI、要极致刷新RGB565 预生成 pushImage必要时 RAM 缓存当前页。要透明/抗锯齿、底色可能不纯黑ARGB8888 pushAlphaImage。图很少、想少维护资源PNG 首次解码缓存即可。列表里很多张大图优先减小尺寸如_25w 原始像素再考虑页级缓存而不是全库常驻。7. 相关 APIM5GFX / LovyanGFXAPI用途drawPngFile(FS, path, ...)从文件系统解码 PNGpushImage(x, y, w, h, rgb565*)推送 RGB565无 AlphapushAlphaImage(x, y, w, h, argb8888*)推送带 Alpha 的 32bpp 并混合readRect(...)读回屏上像素便于「解码一次再缓存」
ESP32-S3 屏幕显示图片格式对显示速度的影响 png rgb565
ESP32-S3 屏幕显示图片格式对显示速度的影响 png rgb565针对 CardputerESP32-S3 SPI RGB565 屏固件中的图标绘制。相对耗时为经验量级非精确 benchmark同尺寸对比以RGB565 已在 RAM、pushImage为1×。1. 结论先看同尺寸下常见路径大致是RGB565 直推 ≫ ARGB8888 Alpha 混合 ≫ 每次现场解 PNG优先级做法适用要最快预生成RGB565透明烤进黑底→pushImage底色固定为黑的 UI 图标要透明叠任意底预生成ARGB8888→pushAlphaImage需要半透明/抗锯齿叠在多变底色上要省 Flash、改图方便保留PNG首次解码后RAM 缓存数量少、可接受首次卡顿不推荐反复每次drawPngFile列表翻页、按键闪烁等高频重绘面板最终都是RGB565ARGB8888 / PNG 都会在上屏前变成 16-bit。2. 各路径实际在做什么2.1 PNGdrawPngFileLittleFS 读文件 → zlib 解压 → PNG filter 还原 → 颜色/透明处理 → 写屏慢主要慢在CPU 解码zlib filter不是 30×30 像素本身。有 Alpha 时由 M5GFX/LovyanGFX 做混合画质通常最好、也最省 Flash。每次重绘都走全流程就会明显卡空调模式切换、米家列表等。2.2 预生成 RGB565.rgb565LittleFS 读原始像素 → pushImage直接写屏无 zlib、无 Alpha 混合Flash / SPI 约为 ARGB 的一半。不支持透明通道透明区需提前合成到固定底色本项目 UI 多为黑底。手写转换若处理 Alpha/抗锯齿不当观感会明显差于库解码 PNG应用「与屏上一致」的像素例如库解码后再落盘画质才可靠。2.3 预生成 ARGB8888.argb8888LittleFS 读原始像素 → pushAlphaImage读底色 混合 写回跳过 zlib保留完整 Alpha。字节序需与lgfx::argb8888_t一致B, G, R, A见scripts/png_to_rgba8888.py。比 RGB565 慢主要因为逐像素 Alpha其次是 4 字节/像素的读写量。2.4 PNG 解码一次 RAM 缓存首次drawPngFile → readRect 存 RGB565 之后pushImage画质对齐库解码重绘接近 RGB565 直推。占 RAM宽 × 高 × 2 × 槽位数空调 8 张 30×30 ≈ 14 KB。3. 相对耗时同分辨率路径相对耗时说明RGB565 已在 RAM →pushImage1×最快RGB565 从 Flash →pushImage约 1.5–3×多 FS 读ARGB8888 已在 RAM →pushAlphaImage约 3–6×Alpha 混合ARGB8888 从 Flash →pushAlphaImage约 4–8×FS AlphaPNG 每次drawPngFile约 10–40×zlib 解码波动大绝对量级体感参考30×30路径大约RGB565pushImageRAM 1 msARGB8888pushAlphaImageRAM约 2–5 msPNG 现场解码约 10–30 ms70×70大约再乘5–6 倍按面积。若整页还有清屏、大量文字、布局计算图标优化后「体感不明显」是正常的——瓶颈可能不在图标。4. Flash / RAM 占用同图公式无压缩原始像素RGB565宽 × 高 × 2ARGB8888宽 × 高 × 4PNG视压缩而定通常远小于原始像素尺寸RGB565ARGB888825×25≈ 1.25 KB≈ 2.5 KB30×30≈ 1.8 KB≈ 3.6 KB60×60≈ 7.2 KB≈ 14.4 KB70×70≈ 9.8 KB≈ 19.6 KB本仓库 LittleFS 分区约1.5 MBdefault_8MB.csv的 spiffs。设备图标全套 ARGB 约数百 KB 量级空间一般够用若同时保留 PNG ARGB体积会叠加上去。RAM 策略少量固定图标如空调 8 张可常驻缓存。大量设备图标用暂存缓冲按需从 Flash 读不全量常驻避免上百 KB数 MB RAM。5. 本项目现状实现要点资源格式优先绘制入口空调模式/icon/ir/.argb8888回退 PNGsrc/app_ir.cpp可带槽位缓存设备图标/icon/device/.argb8888回退 PNGsrc/app_device_icons.cppscratch 按需加载Logo/logo_60.argb8888回退 PNGdrawAppLogo60Icons 应用中的设备图同上走drawDevicePngNativesrc/app_icon_demo.cpp箭头 / WiFi / 电池等矢量代码绘制src/app_icons.cpp无图片文件转换脚本python scripts/png_to_rgba8888.py data/icon/ir python scripts/png_to_rgba8888.py data/icon/device data/logo_60.png data/logo_50.png另有历史脚本scripts/png_to_rgb565.py透明合成到黑底若改回 RGB565 路线需保证转换质量后再替换绘制路径。网页配置预览仍使用PNG浏览器友好固件绘制优先原始像素文件。6. 选型建议黑底 UI、要极致刷新RGB565 预生成 pushImage必要时 RAM 缓存当前页。要透明/抗锯齿、底色可能不纯黑ARGB8888 pushAlphaImage。图很少、想少维护资源PNG 首次解码缓存即可。列表里很多张大图优先减小尺寸如_25w 原始像素再考虑页级缓存而不是全库常驻。7. 相关 APIM5GFX / LovyanGFXAPI用途drawPngFile(FS, path, ...)从文件系统解码 PNGpushImage(x, y, w, h, rgb565*)推送 RGB565无 AlphapushAlphaImage(x, y, w, h, argb8888*)推送带 Alpha 的 32bpp 并混合readRect(...)读回屏上像素便于「解码一次再缓存」
