WPF的四种曲线绘制
WPF的四种曲线绘制
在图形开发中，WPF（Windows Presentation Foundation）以其 声明式 UI 模型 和 硬件加速渲染架构 著称，在工控，医疗领域有非常广泛的应用。其中非常重要的一点就是WPF开发效率高，渲染性能好。WPF为我们提供了不同的绘制方式，当我们尝试实时绘制上万甚至数十万个点（如信号曲线、波形图，渲染结果）时，寻找合适的的方式能够提升性显示性能。
本文将从 WPF 的渲染管线 出发，对比几种常见的绘制方案：
- Polyline + Canvas
- Path + StreamGeometry
- DrawingVisual
- WriteableBitmap
并总结它们的性能特点与适用场景。
一、WPF 渲染管线介绍
1. 双线程模型
- UI 线程：负责处理用户输入事件（如 MouseClick、KeyboardInput 等）和布局逻辑（Measure/Arrange），生成设备无关绘制指令，DrawLine等。
- 渲染线程：负责处理设备无关的绘制命令，将其转义成gpu能执行的命令（Direct2D / Direct3D），根据帧率和缓冲情况发送到 GPU。
2. 双树结构
- 逻辑树（Logical Tree）：例如 Window → Grid → Button，描述控件的层级关系，是布局系统的核心(Measure和Arrange，依赖属性），并在逻辑树上传递UI事件（如左键点击，移动），更多强调逻辑功能。
- 视觉树（Visual Tree）：由 Visual对象组成，是最终渲染的核心结构，决定我们能看到什么。
- 两棵树并不是独立的，很多Framework Element在两棵树上都挂载了，对于功能、显示都起作用，但有些东西只在视觉树上。拿Border举例，在xaml中写，则在两棵树中都有。如果只是Button样式中的Border，则wpf只会将其加载到视觉树上渲染。
注意：直接将 DrawingVisual加入视觉树无法显示，必须通过继承 UIElement 的宿主承载（因为只有 UIElement 才具备布局能力）。
3. 渲染流程
- 当修改依赖属性（如 Width、Height）时，会触发 InvalidateMeasure 或 InvalidateArrange，标记为“脏”；
- WPF 向 Dispatcher 添加一个 Render 任务（优先级仅次于 Input）；
- UI 线程首先执行 UpdateLayout()，它会递归调用 Measure / Arrange;然后执行 Render，遍历可视树，调用每个可视元素的 OnRender()；OnRender() 内部通过DrawingContext 记录“设备无关绘制命令”
- 渲染线程按帧率（约 60fps）从缓冲区取命令，转换成Direct3D命令交由 GPU 渲染。
二、不同绘制方式对比
这里通过绘制性能和内存占用来分析各种不同方式的效率，最后给出实验结果图。
1 Polyline + Canvas
特点
基于 UIElement，走完整布局系统，支持交互与命中检测。
绘制流程
List
↓
Polyline.Points (DependencyProperty)
↓
Measure/Arrange 阶段
↓
DefiningGeometry (生成 PathGeometry)
↓
Composition Thread
↓
Direct2D / DirectX
↓
GPU 绘制
性能分析
性能瓶颈在于cpu端，海量的重复操作。
- 短时间内创建上万个对象然后释放，GC内存回收压力非常大，影响渲染速度；
- Polyline的PointCollection的每个点的修改，都会验证当前是否是UI线程，都会Notify关注的对象（如果有）；
优缺点
| 优点 | 缺点 |
|---|---|
| 支持交互（如 MouseOver） | 大量点更新会卡顿 |
| 使用简单 | 每次更新触发布局系统 |
适用场景
非高频更新、可交互矢量曲线。
Path + StreamGeometry
特点
Path参与布局系统，但streamGeometry由数组构成，对于点的修改，不会触发订阅事件。如果是静态数据，能够冻结，进一步提升性能。
优势
- 绘制时直接将浮点数组上传至 GPU；
- 更改点不会触发订阅事件以及UI线程检测；
- 调用 Freeze() 后可极大提升渲染效率（数据不变）。
限制
- 无法增量添加单个点（只能整体重建）；
- 冻结StreamGeometry后不能动态修改；
适用场景
静态曲线（无论是否静态，相比polyline来说，性能肯定是更好的）、批量绘制、大数据展示。
DrawingVisual
特点
脱离布局系统，仅存在于视觉树中，在UI较忙时性能会更好。
使用机制
- 必须挂载在 FrameworkElement 宿主中；
- 更新数据时直接通过宿主公开方法修改 DrawingVisual；
- 不走布局系统，不需要进入 Dispatcher 队列，更新延迟更低。
性能表现
- 最关键的一点是，不走布局系统，无 Measure/Arrange 开销，意味着大量简单绘制，在布局改变时有更好的绘制性能。
- 直接继承至ContainerVisual，相较普通ui元素更加轻量化。对于大量简单绘制，内存占用率更低。
缺点
- 无默认交互支持，需自写 HitTest
💡 适用场景
适用于背景绘制、波形监控、频繁刷新，但交互少的场景。
WriteableBitmap
特点
直接操作像素内存，再上传纹理到 GPU。
机制对比
wpf渲染机制是走绘制命令，将命令传递给gpu绘制。而WriteableBitmap是直接在内存中修改像素，最后将像素数据传送给gpu。
| 上传方式 | 特点 | 性能瓶颈 |
|---|---|---|
| 绘制命令 | 命令小但频繁 | CPU 调用频率高 |
| 纹理上传 | 一次性大数据 | PCI 总线传输 |
特性
- 可直接修改部分像素，非常适合局部更新；
- 绘制密集但内容变化有限时效率极高，内存占用率也极低，只有屏幕像素大小内存占用；
- 因直接操作每一个像素，需自己实现采样、插值、抗锯齿等逻辑。
适用场景
实时波形、光栅化绘制、自定义像素特效。
三、实验结果和性能对比
Polyline和Path+StreamGeometry对比
 1万 Polyline |
 10万 Polyline |
 20万 Polyline |
 1万 Path+Streamgeometry |
 10万 Path+StreamGeometry |
 20万 Path+Streamgeometry |
结果显示，在不同规模数据的性能上，path+streamgeometry都明显要比polyline更好一些
Path+StreamGeometry与DrawingVisual对比
10万 Path+StreamGeometry 与 10万 DrawingVisual 的内存占用
1万 Path+StreamGeometry 与 1万 DrawingVisual 的拖拽表现
-单纯从渲染性能上，其实两者差距很小（尤其是当渲染成为瓶颈，布局系统所消耗的时间就被掩盖了）。
-实验显示，10万个点的内存占用：DrawingVisual因轻量化，内存占用要少的多
-实验显示，1万个点在布局系统改变（width，height等）时引起的重绘时，DrawingVisual就有明显的优势了。
WritableBitmap的极致性能
这两张图时30万个点的渲染和内存占用。这稳定的帧率和86M的内存，足以说明这种方式的高效性。
结语
WPF 提供了丰富的绘制层次，从高层 UIElement 到底层像素操作， 应根据 数据量、刷新频率、交互需求 选择合适方案。个人理解，仅仅polyline的性能就已经非常满足大多数开发需求，如有瓶颈在逐步深入。
- 如果追求 交互性与开发效率：选择
Polyline——支持万级的实时渲染，支持局部调整（自动构建Geometry）； - 如果要 平滑绘制大量点数据：使用
StreamGeometry——牺牲部分交互性（点修改的交互，验证），更快的渲染性能。局部修改，需要手动重新构建整个StreamGeometry； - 若追求 极致实时性能：
DrawingVisual是理想选择——完全舍弃布局系统开销，牺牲更多了交互性，换来稍微的性能提升和更小的内存占用； - 若需要 像素级控制或特效：
WriteableBitmap无可替代——完全绕过wpf的渲染引擎，自己控制每一个像素的值，换来的是极致的性能和内存占用。
浙公网安备 33010602011771号