TouchGFX 4.27 发布：双帧缓冲拆进片内 SRAM，1280×800 从 30fps 干到 60fps

eric2013

https://www.st.com/en/embedded-software/x-cube-touchgfx.html

1、主线一：混合双缓冲，把渲染搬回片内

瓶颈在带宽，不在算力。典型配置 1280×800 RGB TFT @60Hz 配 16bit PSRAM（190MHz DDR），理论带宽只有约 6.1 Gbit/s（≈760 MB/s）。以 STM32H7S 为例，光 LTDC 一路就吃掉 50% 以上外部 RAM 访问，再叠加 HP DMA 和 GPU，读-改-写几乎没剩空间，大尺寸动画必掉帧。

4.27 把帧缓冲拆成两层用：

1、外部 RAM 仍放两个完整帧缓冲，保证无撕裂
2、片内 SRAM 放较小的渲染块（partial framebuffer）
3、TouchGFX 只渲染失效区域，先落在片内块上，再整块拷进外部完整帧缓冲

结果是不再让每个像素的读-改-写都去撞慢速外部存储器，混合（alpha blending）效率明显改善，高分辨率应用省带宽。

官方 1280×800 演示数据：

1、渲染时间 25 ms → 15 ms
2、帧率 30 fps → 60 fps
3、内部 RAM 占用仅 256 KB
4、部分场景渲染时间最多省 50%

2、主线二：增量压缩动画，Flash 最多省 90%

做法是逐帧比对位图序列的差异，只把发生变化的区域存成 delta 帧。关键在于压缩在编译期完成，运行时零开销。

适用场景很明确：启动画面、splash、短的位图动画，也就是帧间只有局部变化、不是整屏刷新的那一类。整屏逐帧变的动画收益有限。

官方给的两个落点是入门级 MCU 和高端图形 MCU 两端：

1、STM32C0 / STM32C5：Flash 本来就紧，省下来的空间直接决定能不能上这个 UI
2、STM32H5 / STM32N6 / STM32H7：性能与资源都宽裕，但动画体积小了，加载和缓存压力同样下降

素材体积最多减少 90%（官方口径）。代价是本版 TouchGFX Designer 里没有配置入口，要在 framework 里配、代码里用新控件调，C++ 动画资源自动生成。

3、主线三：运行时固件更新不再需要停应用

4.27 让设备端更新更灵活，且不用先擦掉正在跑的应用：

1、TouchGFX 启动前，应用先设一个 offset，声明当前生效的是哪个 asset bank
2、TouchGFX 读外部 Flash 里的位图、字体、文本时，自动把 offset 加上

这对 OTA 和「固件更新后复用另一个地址上的资产」直接有用，双 bank 切换不用再改链接脚本去对齐资源地址。