修正板端性能测试误判并加速 framebuffer 提交

板端测试发现轻量 Demo 在未优化 ARM 构建下只有十几帧，但 Release 构建后可达到约 76 FPS。问题主要来自单配置 CMake 构建未默认启用 Release，以及 fb0 提交路径逐像素通用转换成本过高。

本次变更将单配置生成器默认构建类型设为 Release，避免 ARM/fb0 性能测试误用未优化构建；同时为 FBDisplay 增加 RGB565、ARGB8888/XRGB8888、RGBA8888 连续内存等常见格式快速路径。Demo 临时移除旋转正方体，保留 2D sprite、tilemap、FPS 和 Frame/Present 耗时显示，用于定位板端 framebuffer 提交瓶颈。

Constraint: IMX6U framebuffer 性能结论必须基于 Release 构建
Constraint: 核心代码保持 C++11 兼容，不引入新依赖
Rejected: 直接判断板子性能不足 | 未优化构建会严重放大逐像素循环成本
Rejected: 继续优化 3D 正方体路径 | 当前瓶颈已由 Frame/Present 计时证明主要在 fb0 present
Confidence: high
Scope-risk: moderate
Directive: 后续板端性能测试先确认 CMAKE_BUILD_TYPE=Release，再分析算法瓶颈
Directive: 2D-only 场景不要使用会清 depth buffer 的 DrawContext::clear()
Tested: cmake --build build-win --config Release
Tested: wsl bash -lc "cd /mnt/d/source/IMX6U-Game && cmake --build build-arm-fb"
Not-tested: 实机 framebuffer 像素格式以外的非常见 fb0 layout

docs/APP_AND_GFX_ARCHITECTURE.md

@@ -20,7 +20,7 @@ IMX6U-Game/
 │  │  ├─ Platform/         # SDL2 / fb0 显示适配与独立时间源（✅ 已实现）
 │  │  └─ Asset/            # 资源加载（✅ 已实现）
 │  ├─ Apps/
-│  │  ├─ Demo/             # 当前 3D 立方体 demo（✅ 已实现）
+│  │  ├─ Demo/             # 当前板端性能 demo；历史上也用于 3D 立方体验证（✅ 已实现）
 │  │  ├─ Launcher/         # 启动器应用（待实现）
 │  │  ├─ GameA/            # 第一个游戏（待实现）
 │  │  └─ GameB/            # 第二个游戏（待实现）
@@ -226,7 +226,7 @@ namespace Gfx
 4. ~~底层代码迁移到 `src/Gfx/`，Demo 入口迁移到 `src/Apps/Demo/`。~~ **已完成**
 5. 新增 Launcher app，只做最小菜单和应用切换。
 6. 新增 GameA/GameB 空壳，验证三应用切换。
-7. 再逐步把现有 3D demo 或 2D 游戏逻辑迁入对应 Game 目录。
+7. 再逐步把现有 3D demo 能力恢复为独立验证入口，或把 2D 游戏逻辑迁入对应 Game 目录。
 8. 最后重构 CMake，按 `imx6u_gfx` + 应用 target 拆分。
 
 ## 8. 性能注意事项
@@ -237,6 +237,9 @@ namespace Gfx
 - Launcher 不应常驻消耗大量纹理/音频资源；进入游戏后可释放非必要启动器资源。
 - Gfx 的绘制函数要保持小而直接，优先内联和连续内存写入。
 - UI 控件层可以面向对象；像素/quad/sprite/tile 绘制层不要过度抽象。
+- 无 3D 内容的 2D 应用应使用只清颜色缓冲的路径，避免每帧清理 depth buffer。
+- `/dev/fb0` 后端提交可能是主要瓶颈；板端性能分析应拆分 `Frame` 和 `Present` 耗时，并确认 ARM 构建为 Release。
+- 直接写 framebuffer 不是原子换屏，LCD 扫描会让局部动画看起来比完整帧率更连续；判断性能应以计时数据为准。
 
 ## 9. 资源转换约定
 

docs/DEVELOPMENT_GUIDELINES.md

@@ -87,11 +87,31 @@
 ## 5. 渲染管线性能规范
 
 - FrameBuffer / DepthBuffer 清理必须优先考虑批量填充（如 `memset`、`std::fill`、平台优化路径），不要逐像素走复杂逻辑。
+- 2D-only 或不使用深度测试的场景应只清颜色缓冲，例如使用 `DrawContext::clear_color()`；不要每帧无意义清理 depth buffer。
 - 像素写入路径应尽量减少分支和函数调用层级。
+- 像素级写入的 Release 快路径不要使用带额外边界检查的容器访问（例如 `std::vector::at()`）；边界检查应在外层完成。
 - 裁剪、剔除、包围盒收缩要尽早执行，避免把不可见数据送入像素级循环。
 - 三角形属性插值、深度测试、纹理采样等未来功能必须先定义定点/整数方案，再接入热路径。
 - PC 调试版可以保留更易读的检查与可视化代码，但 ARM release 路径必须能关闭这些额外成本。
 
+### 5.1 `/dev/fb0` 提交路径
+
+Framebuffer 后端是 IMX6U 上最容易误判性能的路径。`FBDisplay::present()` 需要把 CPU 侧 framebuffer 写入 `/dev/fb0`，如果逐像素走通用格式转换，整屏 1024x600 提交会成为主瓶颈。
+
+规范：
+
+- ARM / framebuffer 性能测试必须使用 Release 构建；单配置生成器应确认 `CMAKE_BUILD_TYPE=Release`。
+- 性能结论必须拆分 `Frame` 和 `Present` 耗时；如果 `Present` 接近 `Frame`，优先优化显示提交，而不是游戏逻辑。
+- fb0 像素格式应在初始化时打印并据此走专用路径，常见格式包括 RGB565、ARGB8888/XRGB8888、RGBA8888。
+- 避免每帧重复做不必要的通用 RGBA 转换；可考虑目标格式 backbuffer、预转换资源、行拷贝、dirty rect 和局部提交。
+- 直接写 `/dev/fb0` 不是原子换屏；LCD 控制器可能边扫描边显示正在写入的内存，因此肉眼流畅度不等同于完整帧率。
+
+已观察到的板端测试结论：
+
+- 未优化 ARM 构建下，轻量 2D demo 曾出现约 `Frame:81ms / Present:69ms`。
+- 改为 Release 构建后，同一类 framebuffer 测试最高约 76 FPS。
+- 因此板端性能测试首先检查构建类型，再判断算法或硬件瓶颈。
+
 ## 6. STL 与标准库使用边界
 
 允许：
@@ -129,6 +149,7 @@
 
 新增或修改核心代码前，至少检查：
 
+- [ ] ARM / framebuffer 性能测试是否确认使用 Release 构建？
 - [ ] 是否在热路径新增了 `float` / `double`？如果是，是否能改成整数/定点？
 - [ ] 是否在每帧或内层循环创建了 `std::vector` / `std::string` / 其他堆分配对象？
 - [ ] 容器是否提前 `reserve()`，或由上层复用？
@@ -214,3 +235,11 @@
 - 总帧时间、最低 FPS、峰值帧时间
 
 性能日志默认低频输出，例如每 60 帧汇总一次；ARM release 中不得逐帧大量打印。
+
+Framebuffer 对照后端同样需要至少显示或记录：
+
+- `Frame`：从帧开始到提交完成的总耗时；
+- `Present`：`IDisplay::present()` 的耗时；
+- 当前 FPS。
+
+当前 Demo 的板端测试 UI 已包含这些信息，后续正式 profiler 可替代该临时显示。