CAD缩放架构

有，而且启发还挺明确。Spark 的 DisplayCore 流畅，不是因为“缩放公式更高级”，而是因为它的显示架构比我们现在这版 CAD 交互更像实时显示控件。

我对比后，关键差异有这几个：

1. Spark 的输入到刷新链更短。 在 WpfDisplayManager.cs 里，刷新直接 BeginInvoke(DispatcherPriority.Send, ...)，优先级比我们现在常用的 Render / Input 还激进。它的意思是：视口一变，就尽快把新帧送进 WPF。

2. Spark 把“视口变化”和“重绘”解耦了。 在 DisplayManager.cs，缩放本质只是改 DataFov。真正的绘制由 DataCollectThread.cs 的后台采集线程持续刷新，而且它还是双缓冲的。也就是说，滚轮/框选时主线程主要是在改视口状态，不是每一下都自己扛完整渲染生命周期。

3. Spark 的矩形框选缩放是“立刻提交新 FOV”。 看 DispRectZoomCmd.cs，框选结束后直接 DisplayManager.DataFov = newFov;。而我们现在 CAD 路径是 FinishCadSelection() -> ScheduleCadRender() -> Task.Run(RenderCadViewport)，中间多了一层请求排队和异步 render 完成等待。

4. 你现在 CAD 模式的卡感，主要来自“每次缩放都要重新 rasterize CAD”。 我们当前实现里，滚轮缩放在 BoardImageWpfView.xaml.cs 调 ZoomCadViewport()，最终走到 RequestCadRenderAsync()，每次都会 Task.Run(() => _viewModel.RenderCadViewport(...))。这跟位图模式完全不同，位图只是在本地改 transform / viewport buffer，所以当然更顺。

所以我的判断是：

• 现在这点“总有一点延时”，不是 bug
• 是架构差异导致的感知延迟
• Spark 更像“持续显示引擎”
• 我们现在更像“事件驱动的逐次重渲染”

能做的优化，按收益从低风险到高收益排：

1. 低风险： 把 CAD 的滚轮和框选缩放做成“交互预览 + 渲染追帧”。 也就是先立刻用现有 BoardImage 做一次临时 scale/translate 预览，让手感先顺；后台 CAD 真渲染回来后再替换真实帧。这个最像 Spark 的体感优化，而且不需要重写 CAD 服务。

2. 中风险： 给 CAD 缩放增加节流/合并。 现在每次滚轮都可能发起一次 render 请求。可以改成连续滚轮期间只保留最后一次 ROI，请求合并，减少无效中间帧。

3. 中高风险： 做 CAD 视口缓存。 比如缓存最近几级 ROI/pixelWidth/pixelHeight 的 render 结果，滚轮来回缩时直接命中附近帧，减少 RenderCadViewport() 次数。

4. 高风险但最接近 Spark： 把 CAD 渲染改成专门的持续刷新/双缓冲显示线程。 这基本就是把现在 ScheduleCadRender/RequestCadRenderAsync 重构成一个 mini DisplayCore，收益最大，但改动也最大。

如果你要我给一个最值得先做的方向，我推荐第 1 个： CAD 缩放时先做本地预览，再异步补真图。 这通常能把“总有一点延时”的主观感觉降很多，而且对现有代码侵入相对可控。

如果你同意，我下一步就直接按这个方向给 CAD 缩放和框选放大做一版低风险优化。