1. 课程导入
各位好，我是老张。做嵌入式图形这行十几年了，今天咱们来聊聊TouchGFX的图形加速。说实话，很多工程师把TouchGFX当成一个普通的UI库来用，觉得它只是画得快一点。其实不然，它的底层有一套非常精巧的加速机制。
我刚开始接触TouchGFX时，也犯过傻——以为只要把界面画出来就行，性能不够就换主频更高的芯片。后来被现实狠狠教育了一顿。嗯，咱们今天就从最基础的概念讲起。
什么是图形加速？
图形加速，说白了就是让画面渲染这件事跑得更快。你想想看，一个嵌入式设备要显示60帧的动画，每帧只有16.6毫秒。在这点时间里，CPU要处理触摸事件、更新业务逻辑、还要把像素刷到屏幕上。如果全靠CPU硬算，那画面卡顿是必然的。
图形加速的核心思路就一句话：把重复性高、计算量大的图形操作，从CPU手里交给专门的硬件去做。
关键认知：图形加速不是让CPU跑得更快，而是让CPU少干活。把像素搬运、颜色混合、图层合成这些脏活累活，甩给硬件加速器去处理。
举个例子，你要在屏幕上画一个带透明度的圆形按钮。CPU做这件事，需要逐像素计算颜色混合，一个320x240的按钮就是76800次运算。而硬件加速器可能一次DMA传输就搞定了。差距有多大？我测过，同样的效果，纯软件渲染要8ms，硬件加速只要0.3ms。
为什么需要图形加速？
这个问题我问过不少刚入行的朋友。他们的回答往往是「为了流畅」。对，但不全对。我总结了几条硬道理：
- 帧率是用户体验的命门——低于30帧，人眼就能感知到卡顿。现代消费电子设备，60帧是及格线。没有加速，很多MCU根本扛不住。
- CPU资源是有限的——嵌入式设备不像手机，CPU主频往往只有几百兆。你让CPU既跑业务逻辑又做图形渲染，那应用响应速度必然受影响。
- 功耗和发热——纯软件渲染时CPU一直满载，芯片发热严重。硬件加速器完成同样任务，功耗可能只有CPU的十分之一。
- 复杂特效成为可能——没有加速，你只能做简单的色块和文字。有了加速，抗锯齿、透明度混合、硬件裁剪这些高级效果才能落地。
我的经验：曾经有个项目，客户要求做动态仪表盘，指针每秒刷新50次。用纯软件渲染，CPU占用率直接飙到85%，系统其他任务全被卡死。后来切到硬件加速，CPU占用降到12%，指针还更顺滑了。这就是加速的价值。
TouchGFX中的加速架构概览
TouchGFX的加速架构，我习惯把它理解成「三层接力」的模型。每一层负责不同粒度的加速任务，层层递进。
下面这张图是我自己画的，把整个架构串起来了。你看完应该能有个整体印象。
这张图里三层的关系，我展开说说。
第一层：应用层加速
这一层是纯软件层面的优化，不需要硬件支持。TouchGFX在框架层面做了大量工作：
- 脏矩形算法——只刷新画面中变化的部分，不动的地方不重绘。我见过有人把整个屏幕当画布，每帧全刷，那性能肯定上不去。
- 纹理图集——把多个小图片打包成一张大纹理，减少纹理切换次数。这个技巧在资源紧张时特别管用。
- 缓存复用——静态元素只渲染一次，存到缓存里，后面直接拿来用。
第二层：框架层加速
这一层是TouchGFX的HAL（硬件抽象层）在发挥作用。它把硬件能力封装成统一的API，上层调用时不用关心底层是什么芯片。
- DMA2D控制器——这是ST系列MCU的标配，专门做2D图形加速。颜色填充、像素拷贝、颜色格式转换，它都能干。
- 双缓冲/三缓冲——解决画面撕裂问题的经典方案。一帧在显示，另一帧在后台绘制，交替进行。
- 垂直同步——让帧缓冲切换和屏幕刷新同步，避免画面撕裂。
注意：我曾经踩过一个坑——以为开了DMA2D就万事大吉了。结果发现DMA2D和CPU争总线带宽，导致CPU被饿死。后来调整了DMA2D的优先级和传输块大小，才把性能调平衡。所以加速不是简单「打开开关」，需要根据实际场景调参。
第三层：硬件层加速
这一层依赖芯片厂商提供的硬件模块。不同厂商、不同系列差异很大：
| 硬件模块 | 典型芯片 | 加速能力 |
|---|---|---|
| LTDC | STM32F4/F7/H7 | 多层显示合成、硬件裁剪、颜色查找表 |
| Chrom-ART | STM32F7/H7 | DMA2D增强版，支持图像旋转、缩放、颜色格式转换 |
| NeoChrom GPU | STM32U5/MP1 | 完整2.5D GPU，支持矢量图形、抗锯齿、复杂混合 |
| 硬件图层 | 多数MCU+LTDC | 2~4个独立硬件层，无需软件合成 |
你看这个表格，从低端到高端，硬件加速能力是阶梯式上升的。选芯片时，一定要先评估你的UI复杂度，再决定需要哪一级加速。
加速架构的核心逻辑
说了这么多，其实TouchGFX的加速哲学就一句话：能不画就不画，能少画就少画，必须画就让硬件画。
我举个例子你就明白了。假设你要做一个设置页面，上面有10个开关按钮。用户只点了一个开关，其他9个都没变。没有加速的框架会怎么做？它会重新渲染整个页面。而TouchGFX呢？它只重绘那个被点击的开关区域，其他9个直接从缓存里拿。这就是「能不画就不画」。
再比如，你要做一个渐变色背景。纯软件渲染需要逐像素计算颜色插值，CPU忙得团团转。而TouchGFX会把这个任务交给DMA2D，它一条指令就能完成整片区域的渐变填充。这就是「必须画就让硬件画」。
避坑指南：我刚开始用TouchGFX时，总喜欢把所有控件都设成透明背景，觉得这样好看。结果性能一塌糊涂。后来才明白，透明意味着每一帧都要做颜色混合，这是最耗时的操作之一。能不用透明就别用，能用纯色背景就用纯色。这个教训，是用加班换来的。
小结
图形加速不是什么玄学，它就是一套「让合适的硬件做合适的事」的方法论。TouchGFX把这件事封装得很好，你不需要成为硬件专家也能用好它。但如果你想真正调优性能，理解这三层架构是必须的。
嗯，这一章就到这里。记住那个三层模型，后面我们会一层一层拆开来看。