渲染引擎优化：从脏矩形到硬件加速

渲染引擎是GUI的“心脏”。它跳得快不快，直接决定了用户手指滑动时画面跟不跟手。今天咱们聊聊渲染引擎优化的四个核心武器：脏矩形算法、局部刷新策略、缓冲机制、硬件加速。这些技术我几乎在每个项目里都折腾过，踩过坑，也填过坑。

2.1 脏矩形算法：只画该画的部分

脏矩形（Dirty Rect）是什么？说白了，就是记录屏幕上哪些区域“变脏了”，需要重绘。没变的地方，坚决不碰。

我早期做过一个智能手表项目，屏幕只有1.3寸，分辨率240×240。一开始全屏刷新，帧率只有15fps，滑动列表卡得不行。后来上了脏矩形，帧率直接跳到45fps。你想想看，差别有多大。

2.1.1 基本原理

脏矩形的核心逻辑就三步：

1. 标记脏区：当某个控件状态变化时，把它所在的矩形区域标记为“脏”。
2. 合并脏区：多个脏区如果有重叠或相邻，合并成一个更大的矩形，减少绘制次数。
3. 只绘脏区：渲染引擎只处理合并后的脏矩形区域，其他部分保持不动。

这里有个关键点——合并策略。我见过有人把全屏所有脏区合并成一个整屏矩形，那还不如全屏刷新呢。合理的做法是：

• 如果脏区数量少（比如1-3个），直接分别绘制。
• 如果脏区数量多且分散，合并成几个大矩形，但不要合并成整屏。
• 如果脏区覆盖面积超过屏幕的70%，干脆全屏刷新——合并计算的开销反而更大。

2.1.2 脏矩形的数据结构

实际工程中，脏矩形通常用链表或数组管理。我习惯用“区域链表+裁剪矩形”的组合：

// 脏矩形节点
typedef struct DirtyRect {
    int16_t x, y;      // 左上角坐标
    int16_t w, h;      // 宽高
    struct DirtyRect *next;
} DirtyRect_t;

// 渲染引擎维护一个脏矩形链表
DirtyRect_t *g_dirty_list = NULL;

// 标记脏区
void mark_dirty(int16_t x, int16_t y, int16_t w, int16_t h) {
    // 1. 先尝试与现有脏区合并
    // 2. 合并失败则新建节点插入链表
    // 3. 检查总脏区面积是否超过阈值
}

// 执行渲染
void render_dirty() {
    // 1. 合并相邻/重叠脏区
    // 2. 遍历链表，对每个脏区执行裁剪绘制
    // 3. 清空链表
}

嗯，这里要注意：链表节点不要动态分配。我在项目里吃过这个亏——频繁malloc/free会导致内存碎片，跑几天就崩了。建议用静态数组预分配节点池，用空闲链表管理。

2.2 局部刷新策略：怎么画更聪明

脏矩形告诉引擎“画哪里”，局部刷新策略告诉引擎“怎么画”。这两者配合好了，性能才能上去。

2.2.1 分层刷新

我做过一个车载仪表盘项目，指针、数字、背景三层分开渲染。背景几乎不变，数字每秒更新一次，指针每10ms更新一次。如果混在一起刷，指针的频繁更新会拖累数字和背景。

分层策略很简单：

• 静态层：背景、边框等不变元素，只画一次，存入缓冲区。
• 半动态层：数字、图标等低频更新元素，按需刷新。
• 动态层：指针、动画等高频率更新元素，独立脏区管理。

层级	更新频率	典型元素	刷新策略
静态层	几乎不变	背景、边框、标题	一次渲染，缓存复用
半动态层	秒级更新	数字、文字、状态图标	按脏区局部刷新
动态层	毫秒级更新	指针、进度条、动画	独立脏区，高频刷新

2.2.2 裁剪优化

局部刷新时，每个控件都要做裁剪（Clipping）。裁剪的目的是确保绘制不超出脏区范围，避免破坏相邻区域。

我曾经遇到一个bug：进度条更新时，旁边的文字被“擦掉”了一半。查了半天，发现是裁剪矩形没算对，绘制越界了。后来加了个断言检查，每次绘制前验证裁剪区域是否合法。

2.3 双缓冲与三缓冲机制

缓冲机制解决的是“画面撕裂”和“帧率抖动”问题。说白了，就是让绘制过程和显示过程解耦。

2.3.1 双缓冲

双缓冲是最常用的方案。两个缓冲区：一个用于显示（Front Buffer），一个用于绘制（Back Buffer）。绘制完成后，交换指针。

优点很明显：用户看不到绘制过程，画面完整、无撕裂。缺点是多占一倍内存。对于320×240的16位色屏幕，双缓冲需要额外300KB左右。在资源紧张的MCU上，这可不是小数目。

// 双缓冲交换示例
void swap_buffers() {
    // 等待垂直消隐（VSync）
    while (!is_vsync());
    
    // 交换缓冲区指针
    uint16_t *tmp = front_buffer;
    front_buffer = back_buffer;
    back_buffer = tmp;
    
    // 更新LCD起始地址
    LCD_SetAddress(front_buffer);
}

我个人习惯在VSync期间做交换，这样能彻底避免撕裂。但要注意：如果绘制时间超过一帧，VSync等待会导致帧率下降。这时候就需要三缓冲了。

2.3.2 三缓冲

三缓冲在双缓冲基础上再加一个缓冲区。三个缓冲区轮流使用：一个显示、一个绘制、一个等待。这样即使绘制偶尔超时，也不会阻塞显示。

三缓冲的代价是内存占用更高。我一般只在以下场景使用：

• 绘制时间不稳定，有时超过帧周期。
• 需要保证最低帧率，不能掉帧。
• 内存相对充裕（比如有外部SDRAM）。

方案	内存占用	抗撕裂	抗掉帧	适用场景
单缓冲	低	差	差	极低资源、无动画
双缓冲	中	好	中	大多数嵌入式GUI
三缓冲	高	好	好	高性能、动画复杂

2.4 硬件加速：让GPU干活

很多MCU和MPU都带了2D图形加速单元，比如STM32的DMA2D、NXP的PXP、全志的DE。这些硬件能帮你做位块传输（Blit）、颜色格式转换、Alpha混合等操作，速度比CPU快一个数量级。

2.4.1 GPU Blit 调用

Blit（Bit Block Transfer）是硬件加速的核心操作。说白了，就是把一块内存区域快速拷贝到另一块区域，过程中可以做各种处理。

我做过一个对比测试：在i.MX RT1050上，用CPU做320×240的ARGB8888拷贝，耗时约3ms；用PXP硬件加速，耗时仅0.3ms。差了10倍。

// 伪代码：调用硬件Blit
void hw_blit(
    uint16_t *src, int src_w, int src_h,
    uint16_t *dst, int dst_x, int dst_y,
    int blit_w, int blit_h
) {
    // 配置DMA2D源地址、目标地址、像素格式
    DMA2D->FGMAR = (uint32_t)src;
    DMA2D->OMAR  = (uint32_t)dst;
    DMA2D->FGOR  = src_w - blit_w;  // 源行偏移
    DMA2D->OOR   = LCD_WIDTH - blit_w; // 目标行偏移
    DMA2D->NLR   = (blit_h << 16) | blit_w;
    
    // 启动传输
    DMA2D->CR |= DMA2D_CR_START;
    
    // 等待完成（或使用中断）
    while (DMA2D->CR & DMA2D_CR_START);
}

2.4.2 硬件加速的适用场景

不是所有操作都适合硬件加速。我总结了几条经验：

• 大块拷贝：超过64×64的矩形区域，硬件加速收益明显。
• Alpha混合：硬件做混合比CPU快很多，尤其是半透明UI。
• 颜色格式转换：比如RGB565转ARGB8888，硬件一条指令搞定。
• 小图标的频繁更新：如果图标只有16×16，CPU直接拷贝可能更快——硬件启动有固定开销。

2.5 知识体系总览

下面这张图把本章的核心逻辑串起来了。从脏矩形的标记，到局部刷新的分层策略，再到缓冲机制的选型，最后落到硬件加速的调用——这是一条完整的优化链路。

这张图把四个技术点的关系画得很清楚。你可以把它当作优化时的检查清单：先看脏矩形是否生效，再看局部刷新策略是否合理，然后确认缓冲机制是否匹配，最后检查硬件加速有没有用上。