SDL2渲染146735个2x2方块帧率过低，求高效渲染方案

问题背景 #

我开发了一款一维元胞自动机打印机，使用SDL_RenderFillRect()/SDL_RenderFillRects()绘制细胞。视图支持多缩放级别，在最低缩放级（方块宽度2px）下，渲染规则30时需绘制146735个2x2 px的方块（总像素586940），但帧率未达预期。

帧率测试数据 #

• 循环调用SDL_RenderFillRect()时：
  缩放级别10-6：59fps；5：55fps；4：36fps；3：19fps；2：9fps。
• 改用SDL_RenderFillRects()后帧率提升：
  缩放级别10-3：59fps；2：45fps。

渲染器配置（启用垂直同步和硬件加速）：

...
pRenderer = SDL_CreateRenderer(pWindow, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC);
...

对应渲染代码 #

• 循环调用版本：

// 仅渲染缩放后的内容
for (int i = 0; i < iZoomedCells; i++) {
    if (sCellMap[i].bActive) {
        SDL_RenderFillRect(pRenderer, &sCellMap[i].rCell);
    }
}

• 批量调用版本：

SDL_RenderFillRects(pRenderer, sCellRects, iZoomedCells);

注：黑色区域为背景，未调用RenderFillRect()；规则中黑色区域越多，帧率越高。

我的疑问：SDL_RenderFillRect()/SDL_RenderFillRects()是否适用于该场景？有没有更高效的实现方案？

回答 #

1. SDL_RenderFillRect/FillRects是否适用于该场景？ #

这两个函数是SDL提供的基础矩形渲染接口，但并不适合你这种大规模极小矩形的渲染场景。原因如下：

• 即便SDL_RenderFillRects()是批量提交命令，14万级的小矩形（2x2px）仍然会让GPU承担大量的命令处理开销——GPU的优势在于处理大尺寸、复杂纹理或批量图形，极小矩形的绘制逻辑成本会远超过像素填充本身的开销。
• 硬件加速渲染器的固定管线/着色器针对常规图形优化，大量小矩形的频繁调用会触发不必要的状态切换或命令冗余。

2. 更高效的实现方案 #

方案一：纹理批量渲染（最优解）

将元胞状态预渲染到单个纹理中，再整体绘制到窗口，彻底规避大量小矩形的调用开销：

1. 创建与当前视口匹配的SDL_Texture（推荐使用SDL_PIXELFORMAT_RGBA8888这类硬件友好的格式）。
2. 每次更新元胞状态时：
   • 调用SDL_LockTexture()锁定纹理，获取像素缓冲区指针。
   • 根据元胞激活状态，直接填充纹理中对应区域的像素（比如每个激活元胞对应纹理里2x2的像素块）。
   • 解锁纹理后，用SDL_RenderCopy()将整个纹理一次性渲染到窗口。

这种方式把上万次矩形绘制转化为一次纹理拷贝，GPU只需要处理一次大纹理的渲染，性能会有数量级的提升。

方案二：合并连续矩形

如果不想改用纹理，可以通过合并连续激活的元胞来减少矩形数量：

• 遍历元胞数组，将水平/垂直方向上连续的激活元胞合并成一个大矩形（比如10个连续的2x2方块可合并为20x2的矩形）。
• 合并后再调用SDL_RenderFillRects()批量绘制，能大幅降低提交给GPU的命令数量，缓解性能压力。

方案三：优化渲染器配置（辅助调整）

• 尝试指定具体的渲染器索引（比如0、1）替代-1，部分系统默认选择的渲染器可能不是性能最优的硬件驱动。
• 临时关闭SDL_RENDERER_PRESENTVSYNC测试帧率上限，若要稳定60fps则保留垂直同步，通过前面的方案把渲染效率提至满足垂直同步的要求。

内容的提问来源于stack exchange，提问作者planteater