docs(09-context): record overlay performance discussion

.planning/phases/09-minimum-browser-runnable/09-CONTEXT.md

@@ -286,6 +286,17 @@
 - 完整 UI 形态规范——本阶段无固定约定，由用户按任务逐个提供。
 - 未派发的其余杂项对齐工作——随用户后续增量派发进入 Phase 9 计划，不预先纳入。
 
+### 09-26 覆盖层性能讨论与后续优化（暂不实施）
+
+- **当前排序**：`sortOverlay()` 对「全部静态半透明记录 + 全部活动移动块」做一次全量 `sort`，比较键为 `(layerIndex, y, x, kind)`，复杂度 O(N log N)。
+- **可见性**：覆盖层不做可见分块 / 视口裁剪。非可见分块里的半透明图块仍会参与排序、组装并提交，只是被 GPU 裁剪，不产生片元；不透明遍则通过 `getRenderArea()` 只处理可见分块。
+- **决策**：先不做优化。等渲染端完成后先做基准测试；只有性能不佳再考虑优化。
+- **预期规模**：通常同屏十几个半透明 + 可移动图块，极端情况可能几百个；按此规模，全量排序与组装的成本预计可接受。
+- **待评估优化 1：可见性裁剪**。按可见分块 / 屏幕矩形过滤覆盖层条目；复用 `getRenderArea()` 的可见范围并向外扩「最大图块尺寸 / 格子尺寸」的边距，避免大图块锚点在不可见格但像素伸入画面的情况。可在排序 / 组装附近留 TODO 注释。
+- **待评估优化 2：桶排序**。可按 `(layerIndex, Math.floor(y))` 分桶，桶内再按 `x`（以及 `kind`）排序，复杂度约 O(N + Σ k_b log k_b)。注意：当前比较器使用精确的小数 y，动态块 y=3.4 / 3.7 会按 y 排序；若改成 floor 分桶且桶内只排 x，会改变同一行内动态块的先后。若必须保留小数 y 的精确顺序，桶内仍需按 `(y, x, kind)` 排序，收益会小一些。
+- **其他可选优化**：复用桶数组与条目对象以避免每帧分配；避免每帧 `subarray` 视图；覆盖层上传可用 `bufferSubData` 代替 `bufferData`；大量 `setAlpha` 集中在同一帧时注意 flush 峰值与分块重传。
+- **基准测试关注点**：分别测「无半透明且无动态块」「无半透明但有勇者等动态块」「少量静态半透明」「大量静态半透明 + 每帧移动 / 换帧」；记录帧时间、CPU 排序 / 组装耗时、draw call 数与 GC 情况。
+
 </deferred>
 
 ---