看了项目代码后，一个很强烈的感觉是：Afterglow 已经不只是一个“图片查看器 app”，而是在朝一个 engine-style 的 2D 交互 runtime 发展。当前最有价值的基础其实已经有了：Win32 + Direct2D/DirectComposition 自绘、基于 spring 的交互、分层缓存与缩略图流送、scan cache + persistent thumb cache 的冷启动优化、fast scroll 下的请求失效与每帧 GPU upload budget 等。
我觉得下一步如果想“深化设计”，重点不应该是单纯把 Direct2D 全量替换成 D3D11，而是先把渲染层、资源层、视图层的边界拉清，再在图像层渐进引入 D3D11。这样能保住现有体验，也让后续演进更可控。
当前架构里最值得保留的点
- Application / ViewManager / GalleryView / ImageViewer 这套 engine-style update/render loop
- RequestThumbnail -> readyQueue -> FlushReadyThumbnails 这条缩略图流送路径
- tier2 compressed cache + persistent thumb cache + visible range 优先级
- fast scroll 时 InvalidateRequests + 只显示已缓存缩略图
- 现有 D3D11-backed Direct2D + DirectComposition 的稳定路径
我建议补强的方向
1. 先抽接口，不先重写后端
建议先把这些接口明确下来：
IRenderBackendIImageSource / IFullImageProvider / IThumbnailProviderIViewDataProviderITextRenderer / IEffectLayer
目标是让 GalleryView / ImageViewer 面向“数据和绘制能力”编程，而不是直接依赖 Direct2DRenderer + ImagePipeline + std::filesystem::path / ScannedImage。
2. Direct2D 保持 UI 层，D3D11 先只进入 image layer
当前项目其实已经是 D3D11-backed Direct2D，所以如果未来要上 D3D11，我更倾向于：
- 文本、简单 UI、overlay 继续让 Direct2D / DirectWrite 处理
- 图片本体、大图缩放、颜色/模糊/转场特效先做成可切换的 D3D11 image layer
- 先只覆盖
ImageViewer 和 hero transition，不要一开始全量替换 GalleryView 的所有 2D 绘制
这样更像“混合渲染路线”，风险远低于“纯 D3D11 重写整个 UI”。
3. 把加载链路正式化成独立 pipeline
建议把 pipeline 明确成几个阶段：
- scan / index
- request scheduling
- decode / thumbnail generation
- GPU upload
- eviction / persistence
- telemetry
然后每个阶段都做简单指标：
- thumbnail cache hit / miss
- persistent thumb hit rate
- average decode time
- average upload time
- scroll hitch / dropped frame count
- time-to-first-visible-thumbnail
- cold start vs warm start
这样后面不论继续调 Direct2D，还是引入 D3D11，都能知道性能收益到底来自哪里。
4. 让 progressive scan 真正进入主路径
现在 ScanFolders 已经支持 flush callback，但 Application 里目前是“扫描时只更新蓝条，扫完后一次性重建 gallery”。
我觉得可以把 progressive scan 真正用起来：
- 先展示 cached scan results
- rescan 时按 folder / section 增量合并
- 只对新增或失效的 section 做局部重建
- 让高频访问 folder 的内容更早出现在 UI 上
5. 把缓存策略从“能工作”再推到“可解释”
现在多级缓存已经有了，但可以进一步统一策略：
- 统一 full image / thumbnail / persistent cache 的 budget 和 eviction policy
- visible / near-visible / prefetch 的优先级明确化
- fast scroll / transition / idle 三种状态下采用不同 budget
- 用 small trace / log 输出当前 frame 的 request / decode / upload 状态，方便调优
6. 把 Afterglow 明确定位成“viewer runtime”而不是“若干页面”
我感觉这个项目最特别的地方其实不是某一个控件，而是整体 runtime：
- update / render loop
- scene-like view state
- spring-driven interaction
- resource streaming
- transition orchestration
如果愿意，可以逐步把它沉淀成更清晰的 runtime 内核。未来不只是照片浏览，做视频帧浏览、时间轴、轻量 media canvas 也会更顺。
我建议的渐进路线
- Phase 1: 指标与接口抽象，不改视觉行为
- Phase 2: progressive scan / incremental gallery rebuild
- Phase 3: D3D11 image layer 只接管 viewer + transition
- Phase 4: 如果收益明确，再决定是否扩大 D3D11 覆盖面
为什么我觉得这条路线更稳
因为项目现在最强的地方，其实不是“某个 API 选型”，而是已经形成了一套很有味道的 engine-style 交互与加载系统。先保住这个系统，再扩展渲染后端，成功率会比“先大迁移再回补体验”高很多。
看了项目代码后，一个很强烈的感觉是：Afterglow 已经不只是一个“图片查看器 app”，而是在朝一个 engine-style 的 2D 交互 runtime 发展。当前最有价值的基础其实已经有了：Win32 + Direct2D/DirectComposition 自绘、基于 spring 的交互、分层缓存与缩略图流送、scan cache + persistent thumb cache 的冷启动优化、fast scroll 下的请求失效与每帧 GPU upload budget 等。
我觉得下一步如果想“深化设计”，重点不应该是单纯把 Direct2D 全量替换成 D3D11，而是先把渲染层、资源层、视图层的边界拉清，再在图像层渐进引入 D3D11。这样能保住现有体验，也让后续演进更可控。
当前架构里最值得保留的点
我建议补强的方向
1. 先抽接口，不先重写后端
建议先把这些接口明确下来：
IRenderBackendIImageSource/IFullImageProvider/IThumbnailProviderIViewDataProviderITextRenderer/IEffectLayer目标是让
GalleryView/ImageViewer面向“数据和绘制能力”编程，而不是直接依赖Direct2DRenderer+ImagePipeline+std::filesystem::path/ScannedImage。2. Direct2D 保持 UI 层，D3D11 先只进入 image layer
当前项目其实已经是 D3D11-backed Direct2D，所以如果未来要上 D3D11，我更倾向于：
ImageViewer和 hero transition，不要一开始全量替换GalleryView的所有 2D 绘制这样更像“混合渲染路线”，风险远低于“纯 D3D11 重写整个 UI”。
3. 把加载链路正式化成独立 pipeline
建议把 pipeline 明确成几个阶段：
然后每个阶段都做简单指标：
这样后面不论继续调 Direct2D，还是引入 D3D11，都能知道性能收益到底来自哪里。
4. 让 progressive scan 真正进入主路径
现在
ScanFolders已经支持 flush callback，但Application里目前是“扫描时只更新蓝条，扫完后一次性重建 gallery”。我觉得可以把 progressive scan 真正用起来：
5. 把缓存策略从“能工作”再推到“可解释”
现在多级缓存已经有了，但可以进一步统一策略：
6. 把 Afterglow 明确定位成“viewer runtime”而不是“若干页面”
我感觉这个项目最特别的地方其实不是某一个控件，而是整体 runtime：
如果愿意，可以逐步把它沉淀成更清晰的 runtime 内核。未来不只是照片浏览，做视频帧浏览、时间轴、轻量 media canvas 也会更顺。
我建议的渐进路线
为什么我觉得这条路线更稳
因为项目现在最强的地方，其实不是“某个 API 选型”，而是已经形成了一套很有味道的 engine-style 交互与加载系统。先保住这个系统，再扩展渲染后端，成功率会比“先大迁移再回补体验”高很多。