STM32H743ZIT6 LVGL滑动场景下帧率低

Rhon

如题，笔者使用的主控MCU为STM32H743ZIT6，使用DMA2D+LTDC驱动一块1024*600的RGB屏幕，现在有一个场景就是label组件较多的情况下，上下滑动屏幕会导致帧率低的厉害，在20-30帧左右，这个情况是正常的吗？还有左右滑动时帧率掉到15帧左右。请问各位大佬有没有什么办法优化

regbbs

帮忙删掉这个回复，谢谢

regbbs

这基本正常，尤其是 STM32H743 + LTDC + DMA2D 驱动 1024×600 RGB 屏，在 label 多、滑动频繁重绘时，20–30 FPS 甚至横向 15 FPS 都不奇怪。瓶颈通常不是 LTDC 扫屏，而是：

• label 文本渲染开销大
  
• 滑动导致大面积无效区域重绘
  
• 显存/帧缓冲带宽不足
  
• SDRAM 访问压力大
  
• DMA2D 只能加速填充/拷贝/混合，不能真正加速字体光栅化
  
• 横向滑动比纵向更容易触发整块内容重排/重绘
  
  

优化方向可以按优先级来：
1. 尽量减少 label 数量和重绘面积如果是 LVGL，label 很多时不要直接堆大量 lv_label。可以考虑：

• 用 lv_table、lv_list、自绘列表替代大量独立 label
  
• 只创建屏幕可见区域附近的 item，滑出屏幕后复用控件
  
• 避免每个 item 都有多个 label、图标、背景、阴影
  
• 滑动区域内尽量不要使用复杂样式
  
  

大量 label 的场景，本质上应该做成“虚拟列表”。
2. 打开并检查 DMA2D 加速配置如果是 LVGL，确认类似配置已启用：
#define LV_USE_GPU_STM32_DMA2D 1或 LVGL v9 对应的 DMA2D draw unit 配置。
但要注意：DMA2D 对纯色填充、图片拷贝、透明混合有帮助；对字体渲染帮助有限。label 多时，CPU 仍然可能很忙。
3. 使用双缓冲或局部双缓冲1024×600，RGB565 一帧约：
1024 × 600 × 2 = 1.17 MBRGB888 一帧约：
1024 × 600 × 3 = 1.76 MBH743 片内 SRAM 放不下完整 framebuffer，通常会用 SDRAM。建议：

• LTDC framebuffer 放 SDRAM
  
• LVGL draw buffer 尽量放 AXI SRAM / SRAM，别全放慢速 SDRAM
  
• draw buffer 不一定要全屏，可以用 1/10 屏或若干行
  
• 如果 SDRAM 足够，可尝试双 framebuffer，减少撕裂和等待
  
  

4. 降低色深如果现在是 RGB888 / ARGB8888，建议改成 RGB565：
#define LV_COLOR_DEPTH 16RGB565 对 1024×600 的 MCU 屏幕很常见，带宽压力会明显下降。
5. 优化 SDRAM / FMC 配置1024×600 RGB 屏持续刷新会长期占用 SDRAM 带宽。需要检查：

• SDRAM 时钟是否足够高
  
• FMC 时序是否保守过头
  
• framebuffer 是否 cacheable
  
• MPU 配置是否正确
  
• CPU cache 是否开启
  
• DMA2D、LTDC、CPU 同时访问 SDRAM 是否造成严重竞争
  
  

H743 上建议确认：
SCB_EnableICache();SCB_EnableDCache();同时必须正确处理 DMA2D / LTDC 相关缓存一致性问题。
6. 避免透明、阴影、圆角、渐变滑动区域里这些样式很耗：

• opacity 不是 255
  
• shadow
  
• radius 较大
  
• gradient
  
• border
  
• anti-aliasing
  
• 多层嵌套容器
  
• 背景透明叠加
  
  

列表类 UI 尽量保持“扁平、纯色、少透明”。
7. 字体优化label 多时字体是大头。建议：

• 只使用必要字号
  
• 字体开启裁剪，减少字库体积
  
• 避免频繁更新 label 文本
  
• 中文字体尽量使用子集字库
  
• 常用静态文字可考虑预渲染成图片
  
• 避免滚动时实时格式化字符串
  
  

8. 调整 LVGL 刷新策略检查：
#define LV_USE_PERF_MONITOR 1#define LV_USE_REFR_DEBUG 1看看到底是 FPS 低、CPU 占用高，还是重绘区域太大。
也可以观察：

• 滑动时 invalid area 是否接近全屏
  
• flush_cb 时间是否过长
  
• draw 时间是否过长
  
• DMA2D 是否真的参与了 fill/blend
  
  

结论这个现象在 STM32H743 驱动 1024×600 RGB 屏上算正常范围。H743 虽然强，但 1024×600 + RGB + LTDC + SDRAM + 大量 label 滑动，对 MCU 来说已经是较重负载。
最有效的优化通常不是“把 DMA2D 打开”这么简单，而是：
虚拟列表 + 减少 label 数量 + RGB565 + 优化 SDRAM/cache/MPU + 减少透明和复杂样式。

hpdell

regbbs 发表于 2026-5-8 08:12
这基本正常，尤其是 STM32H743 + LTDC + DMA2D 驱动 1024×600 RGB 屏，在 label 多、滑动频繁重绘时，20– ...

大神总结到位哟

貌似赶脚 h7 驱动 1024*600 的是有点吃力，但驱动 800*480 貌似基本没有什么压力

regbbs

hpdell 发表于 2026-5-8 09:52
大神总结到位哟

貌似赶脚 h7 驱动 1024*600 的是有点吃力，但驱动 800*480 貌似基本没有什么压力

直接问了AI，再修改下，完全自己写的话，花时间会多很多。以后你遇到问题也可以先问AI试试。

hpdell

regbbs 发表于 2026-5-8 10:37
直接问了AI，再修改下，完全自己写的话，花时间会多很多。以后你遇到问题也可以先问AI试试。

改好了吗 ？

Rhon

hpdell 发表于 2026-5-8 09:52
大神总结到位哟

貌似赶脚 h7 驱动 1024*600 的是有点吃力，但驱动 800*480 貌似基本没有什么压力

大佬有做过H7驱动1024*600的相关内容吗

lyj41801

太正常了，我之前就用H7驱动过800*480的屏幕，做了软件旋转，正常操作看不出卡顿，一调出键盘，瞬间掉到15FPS左右。我优化了好久，发现只要去掉了键盘就好了，没法

Rhon

lyj41801 发表于 2026-5-8 17:05
太正常了，我之前就用H7驱动过800*480的屏幕，做了软件旋转，正常操作看不出卡顿，一调出键盘，瞬间掉到15F ...

好吧，那估计只能这样了