Codex
70 lines
2.7 KiB
Markdown
70 lines
2.7 KiB
Markdown
# Fix-BUG-20260415-0006
|
||
|
||
> 适用场景：记录某个 BUG 的修复方案、影响评估、验证结果与落地信息。
|
||
|
||
## 关联信息
|
||
|
||
- Fix ID: Fix-BUG-20260415-0006
|
||
- 关联 BUG ID: BUG-20260415-0006
|
||
- 修复目标: 让托管局部重绘能够正确提交嵌套容器中的脏后代
|
||
- 状态：已完成
|
||
- 负责人: Codex
|
||
- 分支 / 版本: 当前工作区
|
||
|
||
## 根因分析
|
||
|
||
- 根因: 托管局部重绘提交只识别 root 的直接 dirty child，不识别“自己不脏，但下面有 dirty descendant”的直接子分支。
|
||
- 触发条件: 深层按钮状态变化后，叶子控件已 dirty，但中间层 Canvas 自己未 dirty。
|
||
- 为什么之前没发现: 第一阶段主要覆盖顶层和浅层容器，三层嵌套专项场景在 KEY5 重构后才稳定暴露。
|
||
- 关键证据:
|
||
- 按钮 hover / click 回调正常执行
|
||
- 日志正常，但视觉状态直到更大重绘才补出来
|
||
|
||
## 修复方案
|
||
|
||
- 修复思路: 把托管重绘提交从“只认直接 dirty child”改成“识别 dirty descendant，并提升到 root 下直接脏分支提交”。
|
||
- 关键改动:
|
||
- 新增 `hasManagedDirtySubtree()`
|
||
- 新增 `getManagedRepaintDirectBranch(root)`
|
||
- `Canvas / TabControl` 局部提交时，直接子单元若拥有 dirty descendant，也继续 `commitManagedRepaint()`
|
||
- `Window::requestManagedRepaint()` 的 coverage 从最深叶子提升到 root 下直接脏分支
|
||
- 涉及文件 / 类 / 函数:
|
||
- `Control.h / Control.cpp`
|
||
- `Canvas.cpp`
|
||
- `TabControl.cpp`
|
||
- `Window.cpp`
|
||
- 影响的 API / 行为：无公开 API 变化
|
||
- 关键约束 / 不变量:
|
||
- dirty descendant 不能再被中间层漏掉
|
||
- 托管局部提交顺序仍需保持与真实绘制顺序一致
|
||
- 回滚点 / 开关：无
|
||
|
||
## 影响评估
|
||
|
||
- 影响范围: 嵌套 Canvas、页内嵌套容器、深层按钮 hover / click / tooltip 状态刷新
|
||
- 兼容性影响：无
|
||
- 行为变化：有（深层按钮视觉状态会及时刷新）
|
||
- 性能影响：有（coverage 更保守，局部补画可能略增）
|
||
- 回归风险:
|
||
- 局部提交 coverage 扩大后，上层 overlay 补画次数可能增加
|
||
- 需重点回归嵌套容器与顶层 overlay 场景
|
||
|
||
## 验证结果
|
||
|
||
- 验证步骤:
|
||
|
||
1. 编译 `Control.cpp / Canvas.cpp / TabControl.cpp / Window.cpp / z-testDome.cpp`
|
||
2. 使用 KEY5 三层嵌套区作为主回归入口
|
||
3. 检查深层按钮 hover / press / release 是否能即时刷新
|
||
|
||
- 验证结果: 编译通过；逻辑推演闭合；GUI 需用户本机手测
|
||
- 回归检查：KEY5 三层嵌套、页内嵌套、overlay 补画主线
|
||
- 验证证据：编译级验证通过
|
||
|
||
## 落地信息
|
||
|
||
- Commit: 未单独提交
|
||
- PR：[可选]
|
||
- 发布版本：[可选]
|
||
- 备注：该修复为机制修正，不是 KEY5 专项补丁
|