2D图形加速：硬件加速与软件渲染

说到嵌入式GUI的2D图形加速，我脑子里第一个蹦出来的画面，是多年前在一个低端MCU上做菜单动画。那时候不懂什么硬件加速，全靠CPU硬扛，结果一个简单的滑动菜单，帧率掉到个位数。用户一划，屏幕卡成PPT。嗯，从那以后，我就开始认真研究这玩意儿了。

说白了，2D图形加速就两条路：硬件加速和软件渲染。你选哪条，直接决定了你的动画能跑多流畅、功耗能压多低。

硬件加速 vs 软件渲染：核心差异

先看一张对比表，心里有个底：

维度	硬件加速	软件渲染
执行单元	GPU / 2D加速引擎	CPU
并行能力	强（像素级并行）	弱（串行为主）
功耗	低（专用电路）	高（CPU满载）
帧率上限	高（60fps+）	低（受CPU主频限制）
适用场景	复杂UI、动画、视频	简单界面、低功耗待机
开发难度	中（需配置驱动）	低（直接操作帧缓冲）

你想想看，硬件加速就像请了个专业画师，你告诉他「画个圆」，他唰唰几笔搞定。软件渲染呢，就像你自己拿个放大镜，一个像素一个像素地填色。效率能一样吗？

画布(Canvas)操作：你的虚拟画板

Canvas是什么？我习惯把它理解成一块「虚拟画板」。你在上面画东西，最后再一次性刷到屏幕上。这样做的好处是——避免屏幕闪烁。

举个例子，你要画一个按钮，从按下到弹起，中间有颜色变化。如果你直接操作显存，用户会看到「颜色跳变」的瞬间。但如果你先在Canvas上画好，再整体拷贝到显存，用户看到的就只有最终结果。

Canvas操作的核心API一般包括：

• 创建Canvas：分配一块内存，指定宽度、高度、颜色格式
• 清空Canvas：用背景色填充整块画布
• 绘制基本图形：点、线、矩形、圆、三角形
• 裁剪区域：只更新画布的一部分，提升性能
• Blit操作：将Canvas内容拷贝到显存或另一个Canvas

我个人习惯把Canvas分成两种：

• 前台Canvas：直接对应显存，用户看到的就是它
• 后台Canvas：离屏缓冲区，用来做复杂绘制

绘制流程通常是：后台Canvas画好 → 一次性Blit到前台Canvas → 刷新屏幕。这个模式，我称之为「双缓冲」的简化版。

像素操作：从底层理解渲染

像素操作是GUI动画的「原子操作」。你所有的绘制函数，最终都会落到像素级别的读写上。

最基本的像素操作就两个：

1. 读像素：从指定坐标获取颜色值
2. 写像素：将颜色值写入指定坐标

但这里有个坑——颜色格式。不同格式下，一个像素占用的字节数不同，读写方式也不同。

看一个简单的像素写入函数：

// 向Canvas写入一个像素
void canvas_draw_pixel(Canvas *canvas, int x, int y, uint32_t color) {
    if (x < 0 || x >= canvas->width || y < 0 || y >= canvas->height) {
        return;  // 裁剪，防止越界
    }
    
    uint8_t *pixel_addr = canvas->buffer + (y * canvas->stride) + (x * canvas->bytes_per_pixel);
    
    if (canvas->format == COLOR_FORMAT_ARGB8888) {
        *(uint32_t *)pixel_addr = color;
    } else if (canvas->format == COLOR_FORMAT_RGB565) {
        *(uint16_t *)pixel_addr = (uint16_t)color;
    }
    // 其他格式类似处理
}

注意这里的 stride（行跨度）。很多硬件为了对齐，每行实际占用的字节数可能比 width * bytes_per_pixel 大。如果你直接用 width 计算地址，画出来的图会歪掉。我吃过这个亏，调试了一整天才发现是stride没对齐。

颜色格式：ARGB8888 vs RGB565

颜色格式的选择，直接影响你的显示效果和内存占用。嵌入式领域最常用的就是这两种：

格式	位深	每像素字节	颜色数	典型场景
ARGB8888	32位	4字节	1670万色	高画质UI、照片显示
RGB565	16位	2字节	65536色	低内存、简单动画

ARGB8888：每个像素用32位表示，其中Alpha（透明度）占8位，Red、Green、Blue各占8位。好处是颜色丰富，支持透明混合。坏处是——吃内存。一个800x480的屏幕，用ARGB8888需要800×480×4 ≈ 1.5MB的帧缓冲。对于很多MCU来说，这已经是一半的RAM了。

RGB565：每个像素用16位，Red占5位，Green占6位，Blue占5位。没有Alpha通道。内存占用直接减半，800x480只需要约384KB。但颜色精度差一些，做渐变时能看到色带。

我个人的选择原则：

• 如果芯片RAM大于2MB，且需要透明效果（比如弹窗、阴影），用ARGB8888
• 如果RAM紧张，或者只是显示图标、文字，RGB565完全够用
• 如果做视频播放，优先RGB565，因为带宽压力小

颜色格式转换：绕不开的苦活

实际项目中，你经常需要在不同颜色格式之间转换。比如，从SD卡加载一张ARGB8888的图片，但你的屏幕只支持RGB565。这时候就得转。

转换公式其实很简单：

// ARGB8888 转 RGB565
uint16_t argb8888_to_rgb565(uint32_t argb) {
    uint8_t r = (argb >> 16) & 0xFF;
    uint8_t g = (argb >> 8) & 0xFF;
    uint8_t b = argb & 0xFF;
    
    // 高位舍弃，保留高位
    uint16_t r5 = (r >> 3) & 0x1F;
    uint16_t g6 = (g >> 2) & 0x3F;
    uint16_t b5 = (b >> 3) & 0x1F;
    
    return (r5 << 11) | (g6 << 5) | b5;
}

注意，这里有个细节：高位舍弃，保留高位。比如8位的红色值0xAB，转成5位时，取高5位0x15，而不是低5位0x0B。这样能最大程度保留颜色信息。

如果你要做批量转换，千万别在循环里一个一个算。用查表法或者SIMD指令（如果芯片支持），速度能快10倍以上。

知识体系总览

下面这张图，把本章的核心逻辑串起来了：

实战建议：如何选择你的加速策略

说了这么多，到底怎么选？我总结了一个简单的决策流程：

1. 先看芯片手册：有没有2D加速引擎？如果有，优先用硬件。
2. 再看内存：RAM够不够放双缓冲？不够的话，考虑RGB565或者单缓冲+局部刷新。
3. 最后看UI复杂度：如果只是按钮、文字、简单图标，软件渲染+优化裁剪就够了。如果有动画、视频、透明叠加，必须上硬件加速。

嗯，2D图形加速这块，说白了就是「用空间换时间，用硬件换性能」。理解了这个底层逻辑，后面讲动画刷新的时候，你就知道瓶颈在哪、怎么优化了。