WinForms 图表 GPU 性能：

大多数 WinForms 图表对比都从一个错误的前提出发：认为 WinForms 是 WPF 那个陈旧、更慢的兄弟，认真的大数据图表理应属于 WPF。对 ProEssentials 而言恰恰相反。WinForms 接口将 Direct3D 直接耦合到窗口的设备上下文（hDC），从而绕过了 WPF 在结构上必需的 render-to-texture 与 D3DImage 合成器环节——在我们的测试中，这使原生 WinForms 路径的端到端速度比驱动 WPF 控件的同一引擎快约 5%。

本页解释其原因，对比开发者实际评估的八种图表方案的 WinForms 渲染架构，并给出四个可复现的 clone-and-run 演示，使本页的每一项主张都可被验证而非仅凭信任。核心很简单：在 WinForms 上，ProEssentials 在约 15 毫秒内无损渲染 1 亿个点且无数据复制，而且是在其架构上最快的接口上完成的。

亲自复现本页的每一个数字。四个 WinForms 演示，克隆后按 F5：

hDC 优势：为何原生 WinForms 在同一引擎上胜过 WPF

每一个在 WPF 上用 GPU 渲染的图表库都背负着不可避免的架构负担。WPF 通过其自身的合成引擎（Media Integration Layer）掌控屏幕。控件无法像原生窗口那样直接将 Direct3D 绘制到屏幕上——这些像素归 WPF 合成器所有。为注入 GPU 内容，库必须将其 Direct3D 场景渲染到一张离屏纹理，通过 D3DImage（或较新的 composition interop）将该纹理交给 WPF，再让 WPF 合成器在下一个合成器周期将其混合进可视化树。

这一往返并非免费。完成的 GPU 帧被复制到共享 surface，在 Direct3D 与 WPF 渲染线程之间同步，然后在到达屏幕之前由 WPF 第二次合成。每一帧都要为纹理复制和合成器同步付出代价，而这与图表本身绘制得多快毫无关系。

ProEssentials WinForms 控件没有这种负担。作为标准的 System.Windows.Forms.Control，它拥有真实的 Win32 窗口句柄和真实的设备上下文。Direct3D 直接耦合到该 hDC，因此由 Compute Shader 构建的帧被直接呈现到窗口——没有 render-to-texture，没有 D3DImage 移交，没有二次合成。C++/MFC 与 Delphi/VCL 接口同样如此，由于完全没有托管层，它们与 hDC 的耦合更为直接。

实际结果：在各类代表性数据集上，原生 WinForms 接口的端到端测速比驱动 WPF 控件的同一 ProEssentials 引擎快约 5%。Compute Shader、zero-copy 数据路径和 on-demand 帧模型逐字节完全相同——唯一的区别是 WinForms 完全跳过了 WPF 合成器。WinForms 不是 ProEssentials 的折衷接口，而是最快的那个。

WinForms 图表格局并非 WPF 格局

从 WPF 转向 WinForms 时，竞争格局会改变，更重要的是，大多数竞争对手的高性能技术并不会随之而来。多个库大力宣传激进的 Fast Series 或 GPU 渲染，却只在 WPF、WinUI、UWP 上提供这些路径。在 WinForms 上，它们回退到 GDI+、功能精简的 fast view，或干脆什么都没有。弄清哪个对应哪个，比任何单一基准数字都更重要。

ProEssentials：Direct3D Compute Shaders，hDC 耦合

ProEssentials WinForms 控件（PegoWin、PesgoWin、Pe3doWin、PepsoWin、PepcoWin）是标准的 System.Windows.Forms.Control 派生类，使用 Direct3D Compute Shader 完全在 GPU 上构建图表图像。数千个 GPU 核心并行处理每个数据点；CPU 从不遍历数组。完成的帧被直接呈现到控件的 hDC。

大数据渲染通过几个属性启用——PeData.ComputeShader = true 加上 StagingBufferX/Y/Z 标志——数据通过 UseDataAtLocation() 提供，它存储指向你现有数组的指针而非复制数组。没有 float 到 double 的转换，没有逐点对象分配，也没有对数据的托管循环。

管线按需（on-demand）运行：仅当数据或视口确实改变时才绘制。空闲图表消耗零 GPU。这与 WPF 控件是同一引擎、同样的着色器、同样的 zero-copy 路径——但没有 WPF 的 render-to-texture 合成器环节，这正是 WinForms 路径测速更快的原因。

在 RTX 3090 上报告的吞吐量：1 亿个无损点在约 15 毫秒内构建，端到端帧率约 15 FPS，且每帧都包含完整的 1 亿点数据传输——没有重采样，没有降采样，没有任何数据削减。

SciChart：没有原生 WinForms 控件

SciChart 常被誉为最快的 WPF 图表，但它根本没有原生 WinForms 控件。SciChart 自己的文档说明 WinForms 仅通过与 WPF 的集成获得支持——也就是把 WPF 的 SciChartSurface 托管在 Microsoft ElementHost 内。

这意味着 SciChart 的 WinForms 部署继承了 WPF 的所有特性——包括 render-to-texture 合成器路径——再加上 ElementHost 在鼠标事件、焦点和 Z 顺序方面有据可查的 interop 限制。你运行的是穿着 WinForms 外衣的 WPF 控件。

对于真正的原生 WinForms 应用——尤其是带有 Win32/MFC 血统的数据采集软件——没有一流的 SciChart 选项。这个类别中最响亮的性能名号，根本没有推出原生 WinForms 条目。

LightningChart：原生、GPU——连续循环

LightningChart 是最强的真正原生 WinForms 竞争者。它使用底层 DirectX 而非 GDI+ 进行渲染，并宣传极高的容量（早期资料称最高 10 亿个点；当前营销宣称数十亿级的数字）。

其取舍与 WPF 页面一致：连续的 DirectX 渲染循环即使在毫无变化时也让 GPU 保持活跃，因此空闲仪表板仍在绘制帧；并且部署历来需要带有重新激活费用的在线激活——对气隙隔离的工业和国防系统是真切的障碍。

大规模下的无损渲染取决于选择正确的系列类型；错误的类型会在没有编译期警告的情况下，悄然将性能拖慢数个数量级。

DevExpress：SwiftPlot（仅 WinForms，功能精简）

DevExpress 之所以有趣，是因为其快速大数据视图 SwiftPlotSeriesView 仅限 WinForms——WPF ChartControl 中并不存在。DevExpress 宣传无需预处理即可可视化超过 2000 万个点的能力，其可选的 DirectX 模式在 UHD 下比 GDI+ 快达 9 倍。

SwiftPlot 通过一种刻意省略其他视图类型所具备功能的精简生成算法来获得速度，而其底层数据模型仍是逐点对象。在 1 亿点时，这意味着在渲染开始之前要分配数十亿字节的 DataPoint 对象。

对于数万到数百万的范围，它是一个有能力的实时视图，但它是一条以 CPU/GDI+ 为根基、带可选 DirectX 的路径——不是 Compute Shader 引擎，也不是 zero-copy。

Syncfusion：没有 WinForms Fast Series

Syncfusion 为高数据量宣传 Fast Series（FastLineSeries、FastLineBitmapSeries）——但这些仅存在于 WPF、WinUI 和 UWP。WinForms 上没有 fast-series 路径。Syncfusion 自己的支持团队登记了一项为 WinForms 图表添加 fast series 的功能请求，并表示没有立即实现的计划。

即使在 WPF 上，快速路径也是基于 CPU 的：FastLineBitmapSeries 绘制到 WriteableBitmap，在几秒内渲染一百万个点。Syncfusion 还停止了对 DirectX 系列的支持。因此 WinForms 依赖标准 GDI+ 渲染，没有 GPU 加速。

Syncfusion 仍是面向约 10 万点以下业务仪表板的强大通用 UI 套件，但不是大数据量的科学 WinForms 图表引擎。

ComponentOne FlexChart、Telerik、ScottPlot、MS Chart

ComponentOne FlexChart（Mescius/GrapeCity）是一个有能力的原生 WinForms 控件，具有 GDI+ 默认模式和可选的 Direct2D 高性能模式——但其自己发布的性能基准只测试了 100 到 30,000 个点，比 1 亿规模低三到四个数量级。

Telerik RadChartView 在 WinForms 上基于 GDI+；其硬件加速的 Direct2D/Skia 选项仅限 WPF。Telerik 自己的团队表示 90,000 个点对 RadChartView 来说太多，并建议在绘图前对数据进行聚合/平均——一种有损的变通做法。

ScottPlot 是占主导地位的免费/开源选项（基于 CPU，经 System.Drawing 再到 SkiaSharp）。它依赖将数据抽稀到一个代表性子集，而非常大的图（1000 万+ 点）的初始化需要 100+ 毫秒；其维护者指出，点数组在托管与原生之间的封送处理是根本上限。已弃用的 Microsoft Chart（System.Windows.Forms.DataVisualization.Charting）已被正式弃用，基于 GDI+，源自一个基础版 Dundas Chart，并且在现代 .NET（5–8）上不受支持。

On-Demand vs 连续渲染——同样的故事，WinForms 版

WPF 页面中 on-demand 与连续的区分在 WinForms 上同样适用，并且仍是图表选型中最被低估的因素。ProEssentials 仅在数据改变时绘制；LightningChart 的连续 DirectX 循环则无论如何都绘制。在原生 WinForms 控件上，on-demand 帧被直接呈现到 hDC，因此当帧确实发生时，空闲 GPU 的节省不带来任何合成器开销。

On-demand 渲染在主动渲染期间并不更慢——Compute Shader 路径同样快。区别在于帧与帧之间发生了什么：ProEssentials 什么都不做，而连续循环的库则让 GPU 和风扇忙于重绘相同的像素。

GPU Compute Shader 路径如何工作

没有 ComputeShader 时，CPU 在单个核心上顺序遍历每个点来构建顶点数据。使用 PeData.ComputeShader = true 时，GPU 在可能 2,000+ 个核心上并行完成这项工作。在 250 万点 LiDAR 点云上测得的影响：click-to-first-paint 从约 3 秒的 CPU 顶点构建降到几乎瞬时。

StagingBuffer 标志分配 GPU 可访问的中间内存区域，使 CPU 到 GPU 的上传高效进行，而不在传输期间停滞渲染管线。把这四行注释掉即可故意走慢速 CPU 路径——便于前后对比：

// 3D 散点，GPU 顶点构建，呈现到 WinForms hDC
Pe3do1.PeData.ComputeShader  = true;
Pe3do1.PeData.StagingBufferX = true;
Pe3do1.PeData.StagingBufferY = true;
Pe3do1.PeData.StagingBufferZ = true;

关于 WinForms 性能的结论

在 ProEssentials 上，WinForms 不是相对 WPF 的降级——它是更快的接口，因为 Direct3D 绑定到窗口的 hDC，跳过了 WPF 的 render-to-texture 合成器环节，在同一引擎上带来约 5% 的端到端优势。你将获得 GPU Compute Shader、on-demand 渲染、无损保真度和 zero-copy 加载，以及约 15 毫秒内的 1 亿无损点。

在这些替代方案中，SciChart 没有原生 WinForms 控件（仅 WPF-in-ElementHost），Syncfusion 没有 WinForms fast series，Telerik 在建议聚合之前止步于数万个点，ComponentOne 只基准测试到 30K，ScottPlot 进行抽稀，而 Microsoft Chart 已弃用。LightningChart 和 DevExpress 是真正的原生竞争者——两者都有能力，也都带有取舍（连续循环的功耗与激活；功能精简的逐点对象 fast view）。对于数据保真度和大规模性能至关重要的原生 WinForms、C++/MFC 和 Delphi/VCL 图表，ProEssentials 的 hDC 耦合 Compute Shader 引擎是现有最强的技术基础。

1 亿点：完整代码

并排的 C# 代码，精确展示每个库如何处理 1 亿个数据点。

定价与支持

5 年 TCO 对比、支持工单上限，以及当你需要帮助时究竟是谁来应答。

AI 代码辅助

pe_query.py 如何针对编译后的 DLL 验证 AI 生成的图表代码。

技术参考与 Ground-Truth 来源

本页的每一项竞争对手主张均来源于该供应商自己的文档、基准或支持声明。请直接核实：