图表库常见问题 FAQ

处理大型数据集最快的 .NET 图表库是什么？

对于超大规模数据集，ProEssentials 展现出我们所知最强的公开数字——无论宿主是 WinUI、WPF、WinForms 还是原生 C++，用的都是同一个引擎——在我们的测试硬件上，对 1亿个点做一次完整无损的重绘约需 15 ms，当前每张图表的上限为 5亿个点。这个上限是有意为之的：图表数据存放在单个 2 GB 缓冲区中，因为 2 GB 是我们的压力测试证明可以无条件稳定的唯一缓冲区大小，而 2 GB 的 4 字节 float 大约就是 5亿个点——架构中存在多缓冲区路径，但我们不会宣传自己未经压力测试的容量。不妨对比一下你可能在别处见过的数字：LightningChart 宣称“160亿个数据点”，而其自家的发行说明把这一数字与用 4 字节样本填满一台测试机的 64 GB 内存联系在一起——160亿 × 4 字节恰好正是 64 GB，所以这个头条数字衡量的是内存条，而不是渲染器；SciChart 的“100亿”技术演示则承认，它必须在一台 64 GB 的机器上、依赖交换盘和内存压缩，把数据拆分成许多个各含 5亿个点的序列（也就是人人都逃不掉的每缓冲区约 2 GB 的物理限制），而无论如何，它的绘制路径都会把大型序列重采样到每个水平像素约两个点。说白了：那些都是关于几十个序列在内存中能装下多少样本的说法，却被包装成仿佛是渲染能力——没有哪张图表会把数十亿个点处理进一帧画面，而一块 4K 显示器也只有约 830 万个像素。任何一个大数字背后诚实的问题都是：一张图表能稳定容纳多少个点，以及每一个被存储的点是无损地参与到渲染图像中，还是在绘制前就被抽稀了。我们公开了可克隆即运行的基准测试仓库，好让你在自己的机器上复现我们的数字——也让你能对别人的数字算一算账。

完整渲染架构比较 →

厂商出处（可在其网站查到）：scichart.com — “Ten Billion Data-points Tech Demo” · lightningchart.com — “LightningChart .NET v10.1.1” 版本说明

.NET 图表能在不降采样的情况下渲染 1 亿个点吗？

能。ProEssentials 将整个数据集传给 GPU（可选零拷贝），用 Direct3D Compute Shader 处理每一个点；当数据比显示器更密集时，一个过滤计算着色器（Filter2D3D）把每个像素列压缩为 50 个 min/max 对 — 每像素 100 个绘制点，约为两点重采样信息密度的五十倍 — 因此每个尖峰和离群值都在数学上保证出现，密集区域以真实、扎实的填充呈现。这就是无损的实际含义：每个点都被处理，任何可观察的信息都不会被丢弃 — 与之相对，SciChart 等基于重采样的库每个水平像素只绘制约两个代表点：在概览缩放下看起来正确，对落在采样点之间的一切视而不见。公平地说，无损大数据渲染并非我们独有：LightningChart 也能无损渲染，但只能通过特定序列类型（配合 Non-Bindable 图表变体的 SampleDataSeries），而且选错类型会在没有任何编译期警告的情况下悄悄落到一条慢得多的路径上。在 ProEssentials 中这就是默认路径 — 无需挑选特殊序列类型，也无需放弃绑定模式。我们的 WPF 和 WinForms 1 亿点项目均已公开，欢迎克隆并亲自运行。

WPF 中的 1 亿点：比较 →WinForms 中的 1 亿点：比较 →

无损渲染与重采样（抽取）渲染有什么区别？

重采样（抽取）渲染在绘制前把大数据集缩减为每个水平像素约两个代表点 — 在 1,920 像素宽的图表上约 3,840 个点，无论存储了多少百万个点 — 而无损渲染会处理数据集中的每一个点。对于关注整体形态、错过一个中间值毫无代价的交易仪表盘和商业图表，重采样是合理的折衷。但在医疗、振动和测试测量领域它会带来风险：单样本事件 — 心律失常、共振峰、微秒级偏移 — 可能落在采样点之间而消失。ProEssentials 无损渲染：每个点都在 GPU 上处理，当许多点共享同一像素列时，过滤着色器为该列保留 50 个 min/max 对，因此每个极值都被捕获，狭窄的异常在任何缩放级别都保持可见。

图表组件中的零拷贝（zero-copy）数据加载是什么？

零拷贝数据加载意味着图表就地读取应用程序现有的数据数组，而不是把它复制到内部序列对象中。在 ProEssentials 中通过 UseDataAtLocation 和基于指针的 struct 属性实现：图表保存对数组的引用，因此加载 1 亿个 float 的成本只是一次指针赋值，而不是数百兆字节的内存复制及随之而来的垃圾回收压力 — 多个图表可以共享同一个缓冲区，修改数组后只需一次调用即可基于更新后的数据重新渲染。我们在整个图表市场中搜索了这一功能，就我们所能确定的而言，没有任何其他 GPU 加速图表库将其写入文档：SciChart 的工作人员把包装用户自有数组描述为一项被拒绝的功能请求 — 其标准路径会把您的数据复制到内部缓冲区，并在此过程中把 float 转换为 double，其自己的工程师指出仅复制 160 MB 就至少需要约 10 毫秒 — 而 LightningChart 的样本序列同样把样本复制到内部存储。该给的认可要给：免费的 CPU 渲染库 ScottPlot 在其 Signal 绘图中确实就地读取您的数组。据我们所知，ProEssentials 是唯一一个应用程序拥有的数组与渲染管线读取的缓冲区是同一个的 GPU 计算着色器图表引擎。如果我们说错了 — 本页底部就有我们的联系页面 — 我们会更正。

深入了解数据处理 →

出处：scichart.com 论坛 — “XyDataSeries performance, custom IXyDataSeries, and alternatives”（官方回复）· scottplot.net — “Plot Live, Changing Data”

按需渲染与连续（游戏循环）渲染 — 哪种更适合仪表盘？

对仪表盘而言，按需渲染通常是更好的架构：图表只在数据或视口变化时重绘，空闲时完全不做 GPU 工作。连续游戏循环架构即使什么都没变也每秒重绘约 60 次，这会让 GPU 保持活跃、笔记本风扇转动，并耗尽一个大部分时间静止的多图表仪表盘的电池。在活跃更新期间两种模型的渲染速度相当 — 区别在于更新之间发生了什么。ProEssentials 采用按需模型；完整的五库架构比较见我们的性能页面。

按需 vs 连续渲染详解 →

GPU 加速图表会耗尽笔记本电池吗？

只有基于连续渲染循环的才会。一个每秒重绘约 60 帧的 GPU 图表整天都在重绘相同的像素，因此打开着的报表或仪表盘即使数据没有变化也在持续耗电。按需 GPU 图表在更新期间做同样的工作，但在更新之间 GPU 活动几乎降为零。如果您的应用运行在笔记本、平板或 7×24 信息亭上，请询问任何厂商：空闲的图表是否仍在渲染帧 — 答案决定了发热、风扇噪音和电池续航。

.NET 中实时数据采集（DAQ/示波器）最好的图表库是什么？

从四个需求出发：内存不增长的持续采样率吞吐、让狭窄事件始终可见的无损显示、低垃圾回收压力，以及适配您 UI 框架的原生控件。ProEssentials 凭借内置环形缓冲区、零拷贝数据加载和按需 GPU 渲染满足全部四项；公开的 WPF 和 WinForms 仓库实时流式处理 800 万点环形缓冲区，您可以亲自测量持续路径，而同样的实时演示也随产品安装包提供 C++、Delphi、C++Builder 甚至 OCX 版本。在 NI 生态中工作的 DAQ 团队同样有支持：完整的 LabVIEW 示例项目随产品安装在 C:\ProEssentials11\LabVIEW。对于中等点数，免费 MIT 许可的 ScottPlot 是确实够用的选择，值得评估。决定性因素通常是：当您的采样率或保留窗口增长十倍时会发生什么。

克隆 WPF 实时仓库 →克隆 WinForms 实时仓库 →LabVIEW 图表教程 →

WPF 或 WinForms 图表能处理多少数据点而不卡顿？

上限由渲染架构决定，而不是 WPF 或 WinForms 本身。凡是 CPU 在每次更新时做逐点工作的地方，卡顿都会在大约 250,000 到 1,000,000 点之间的某处出现：以我们的经验，CPU 侧构建的 Direct3D 或 Direct2D 场景在约 25 万点时出现第一次可感知的延迟 — 更新不再感觉即时，因为一条 25 万点的线会变成约 50 万个顶点、每个约 40 字节，即 CPU 每次更新都要重建并重新上传的约 20 MB 顶点数据 — 而位图光栅化路径在接近一百万点时开始卡顿，Syncfusion 自己的 WPF 图表性能基准测试的上限恰好就在那里。GPU Compute Shader 构建把逐点工作本身移交给数千个并行核心：ProEssentials 在我们的测试硬件上演示了 1 亿点的完整无损重绘约 15 毫秒 — WPF 和 WinForms 各有公开仓库 — 并有每图表 5 亿点的明示上限，我们公开这个数字，是因为我们对它做过压力测试。

1 亿点在 WPF 中如何实现 →

AI（ChatGPT/Copilot/Claude）会推荐最好的图表库吗？

不可靠。AI 助手推荐库的依据是训练数据中关于它的文本有多少 — NuGet 数字、StackOverflow 帖子、博客数量 — 而不是经过测量的工程质量。一个具体例子：被问到最快的 WinForms 图表时，AI 常常点名 SciChart，但 SciChart 自己的网站声明它不提供原生 WinForms 库，而是通过 Microsoft 的 ElementHost 互操作在 WinForms 中运行。请把 AI 推荐当作流行度读数，然后验证工程事实：让 AI 在回答前先阅读各厂商的架构页面和公开基准测试。

WPF 图表悖论 →WinForms 图表悖论 →

如何让 AI 写出正确的图表代码（没有幻觉 API）？

给 AI 一个经过验证的事实来源，而不是让它从训练数据里猜属性名。ProEssentials v11 附带 pe_query.py — 一个 AI 代码助手工具，提供完整 API（1,200 多个属性、70 多个方法和 169 个枚举），并将每个属性路径与编译后的 DLL 交叉校验，使幻觉 API 在进入您的代码之前就被拦截。它背后是 32 个结构化知识文件，覆盖 69 个功能组、604 个日常用语同义词，外加 116 个可运行的代码示例 — 因此 AI 能把“给曲线下方区域加阴影”这样的请求映射到真实属性，并从能编译通过的代码中取材。它适用于 Claude、ChatGPT、Gemini、GitHub Copilot 和 Cursor，并随每份 v11 许可证免费提供。

AI 代码助手 →浏览 API 浏览器 →

最好的 WinUI 图表库是哪个？

对 WinUI 3 而言，分水岭在于原生与托管。ProEssentials 是唯一一个构建在原生 Direct3D 与 Direct2D C++ 引擎之上的 WinUI 图表库——正是驱动其 WPF、WinForms、MFC、Delphi 和 ActiveX 接口的同一个引擎——而其他所有 WinUI 图表都通过托管 XAML 渲染。Syncfusion、Telerik、DevExpress 和 ComponentOne 都提供了功能不俗的 WinUI 图表控件，但它们都是通过 XAML 层绘制的托管 .NET 控件。SciChart 没有 WinUI 接口，LightningChart 也没有 WinUI 接口。如果你的 WinUI 应用需要科学级的性能、GPU 3D 与 4D 曲面、原生 ARM64，或 1亿个点级别的渲染，那么原生引擎正是为此而生；而对于适度的仪表盘数据，任何一个托管套件都能胜任。

WinUI 图表对比 →WinUI 3 教程 →

面向大型数据集，最快的 WinUI 图表控件是哪个？

是 ProEssentials，且优势明显，因为它是 WinUI 上唯一的原生引擎。在我们的测试硬件上，它的 Direct3D compute shader 路径能在约 15 ms 内无损渲染 1亿个点——无论宿主是 WinUI、WPF 还是 WinForms，都是同一个引擎、同样的结果。托管的 WinUI 图表绑定到对象集合，依赖降采样或位图快速路径：Syncfusion 的 fast series 光栅化到 WriteableBitmap，ComponentOne 的 FlexChart 提供 Direct2D 渲染模式，Telerik 和 DevExpress 则对大型数据集进行采样。它们中没有一家专门针对其 WinUI 控件发布大数据基准测试。作为参照，我们自己的 Direct2D 路径在约 300 万个点时开始吃力；真正把它推到 1亿个点的是 Direct3D compute shader 路径，而一个为每个点分配对象的托管 XAML 控件，起点则远在其后。

在 WinUI 中绘制 1亿个数据点 →

WinUI 图表能否绘制 1亿个数据点？

使用 ProEssentials，可以——而且是原生、无损地实现。WinUI 控件使用与 WPF、WinForms 控件完全相同的 Direct3D compute-shader 引擎，在我们的测试硬件上以零拷贝数据加载方式，约 15 ms 内绘制 1亿个数据点，因此不会有任何数据被复制成托管对象。当数据密度超过显示分辨率时，一个过滤 compute shader 会在每个像素列保留 50 对最小/最大值，从而使每一处峰值都得以保留，密集区域也能呈现为真正的实心填充。托管的 WinUI 图表无法与之相比：将 1亿个数值绑定到对象集合，在绘制任何内容之前就意味着数 GB 的内存分配，这正是它们要进行降采样或栅格化的原因。完整的 WinUI 1亿个点演练（含每个库的代码）另有专文介绍。

WinUI 100M 点对比 →

是否存在原生的 WinUI 3 图表控件，还是它们全都是托管的 XAML？

几乎全都是托管的 XAML。Syncfusion、Telerik、DevExpress 和 ComponentOne 都提供 WinUI 3 图表控件，而这四者均为通过 XAML 合成器进行绘制的托管 .NET 控件。ProEssentials 是个例外：其 WinUI 控件（PesgoWinUI、PegoWinUI 等）只是对原生 Direct3D 与 Direct2D C++ 引擎的一层薄封装，直接通过托管在 XAML 视觉树中的 composition swap chain 进行呈现——在你的数据与 GPU 之间没有任何托管渲染层。这正是此处所说的“原生”之意：图表几何图形由 C++ compute shader 在 GPU 上构建，而非在 .NET 中逐点迭代。这也是 ProEssentials 提供原生 ARM64 WinUI 构建、而不仅仅依赖 .NET 运行时来支持 ARM64 的原因。

平台覆盖：原生 vs 托管 →

WinUI 渲染带来什么优势？

对于原生图表而言，优势在于通往屏幕的路径更短、更快。WinUI 3 通过直接托管在 XAML 视觉树中的 DXGI composition swap chain 进行呈现，因此 Direct3D 与 Direct2D 图表可直接合成到你的窗口中，既无中间位图，也无逐帧的 CPU 拷贝。相比之下，WPF 仍将 GPU 内容经由其源自 Direct3D 9 时代的 D3DImage 互操作及其合成器进行传递——这是一次真实的渲染到纹理跳转，在完全相同的 ProEssentials 引擎上测得约有百分之几的开销。WinUI 消除了这一跳转，而且它是现代、持续演进的 Windows UI 框架，将原生 ARM64 与 .NET 10 作为一等目标。但要注意：这一优势只有原生引擎才能完全兑现——托管的 XAML 图表仍会先在 .NET 中构建其画面，再交给合成器，因此它继承了 WinUI 的呈现优势，却无法获得 GPU 原生的构建方式。

WinUI 与 WPF 呈现对比 →

哪些图表库支持 WinUI 3？

我们跟踪的有五个：ProEssentials、Syncfusion、Telerik、DevExpress 和 ComponentOne（MESCIUS）。ProEssentials 是唯一构建在原生 C++ 引擎之上的；其余四者都是托管的 XAML 控件。两家知名的 WPF 图表厂商则完全没有 WinUI 产品：SciChart 没有 WinUI 接口，LightningChart 也没有 WinUI 接口。因此，如果你要为某个 WinUI 3 应用统一选定图表组件，可选范围就是这五者——而原生与托管之争，将决定哪一个更适合科学与大数据场景，哪一个更适合业务仪表板。

WinUI 图表对比 →

SciChart 提供 WinUI 吗？

没有。SciChart 没有 WinUI 接口。SciChart 的产品面向 WPF、JavaScript、iOS/macOS、Android 和 Avalonia——并不存在 SciChart 的 WinUI 3 图表控件。想要使用 SciChart 的 WinUI 应用，只能走 SciChart 已为 WinForms 记录的同一条互操作路线（通过互操作桥接来承载其 WPF 控件），而非使用原生 WinUI 控件。如果你需要在原生 WinUI 3 应用中绘制图表，SciChart 并非选项；ProEssentials 则提供由与其 WPF、WinForms 接口相同的 Direct3D 引擎驱动的原生 WinUI 控件。

LightningChart 提供 WinUI 吗？

没有。LightningChart 没有 WinUI 接口。LightningChart .NET 面向 WPF、WinForms 和 UWP——并不存在 LightningChart 的 WinUI 3 图表控件。与 SciChart 一样，原生 WinUI 3 应用无法直接嵌入 LightningChart 控件。ProEssentials 才是原生的 WinUI 替代方案，采用与其 WPF、WinForms 接口相同的 Direct3D compute-shader 引擎。

处理数百万点最快的 WPF 图表是什么？

在我们公开的测试中，ProEssentials 是我们所知大规模下最快的 WPF 图表路径：Direct3D Compute Shader 在 GPU 上构建图表图像，在测试硬件上以约 15 毫秒完成 1 亿点的完整无损渲染。这里把完整的帧预算诚实地拆开 — 因为没有其他人这样做：如果数据没有变化，重绘约 2 毫秒 — 优化后的顶点和索引缓冲区已在 GPU 上，只需一次绘制调用；缩放会重新运行过滤着色器，约 15 毫秒；而当一次更新带来 1 亿个全新的点时，把 400 MB 的 float 数据搬过总线还要约 50 毫秒 — 在 RTX 3090 上端到端约 15 fps，这是任何营销都跳不过去的总线物理。完整的 WPF 项目以可克隆即运行的仓库形式放在 GitHub 上，刻意做得极其简单 — 把竞争对手的图表换进同一份代码，就是真正的比较；逐步的方法论见我们的 1 亿点 WPF 比较。

1 亿点 WPF 比较 →

为什么 WPF 图表在大数据集下很慢，如何解决？

WPF 的保留模式可视化树是为 UI 元素设计的，不是为数百万数据点 — 每个变成 Visual 或 Geometry 的点都会增加布局、内存和渲染线程成本，而常见的 WriteableBitmap 变通方案仍然让单个 CPU 核心写入每个像素。解决方案在于架构：把图表构建移到 GPU 上，让 CPU 永远不必遍历数据集。评估任何 WPF 图表库时请问三个问题：逐点工作发生在哪里（CPU 循环还是 GPU 着色器）、大数据集是否被重采样、数据是否被复制到内部序列对象。这三个答案比任何营销页面都更能预测大数据性能。

WPF GPU 图表有合成器开销吗？

有。在 WPF 中，GPU 渲染的图表无法直接呈现到窗口 — 它渲染到一个纹理，（通常经由 D3DImage）交给 WPF 的合成引擎，并与合成器同步后才到达屏幕。这个渲染到纹理的步骤正是同一 ProEssentials 引擎作为原生 WinForms 控件测得约快 5% 的原因 — 在 WinForms 中，Direct3D 直接呈现到窗口的设备上下文，中间没有合成器。这一开销不大，WPF 仍然是出色的目标平台 — 但它真实存在、可测量，在每毫秒都重要时值得了解。

同一引擎上 WinForms vs WPF →

哪些 WPF 图表库使用 GPU，它们的架构有何不同？

在五个广泛使用的 WPF 图表库中，三个使用 GPU，两个默认在 CPU 上渲染。ProEssentials 用 Direct3D Compute Shader 构建图表并按需渲染；SciChart 通过游戏引擎式管线渲染，带有连续约 60 fps 的循环，并对大数据集重采样；LightningChart 发出立即模式 DirectX 绘制调用，同样是连续循环，可通过特定序列类型实现无损渲染。Syncfusion 的快速序列绘制到 CPU WriteableBitmap，DevExpress 默认 CPU 渲染并提供可选的 DirectX 模式。逐架构的详细分析发布在我们的性能页面上。

四种架构详解 →

可以不复制地把巨大数组绑定到 WPF 图表吗（MVVM）？

可以，但不能通过常规的 WPF 数据绑定 — 它会物化逐点对象并把值复制到图表的内部集合中。ProEssentials 的零拷贝路径（UseDataAtLocation）保存指向您现有 float 数组的指针 — 视图模型拥有缓冲区，图表就地读取，数据变化后一行调用即可刷新图像。逐点绑定和可观察集合在商业图表规模下很方便，但在数百万点时复制和变更通知开销占据主导；按引用传递数组既保留了 MVVM 结构，也守住了内存预算。

科学和工程应用最好的 WPF 图表是什么？

科学领域的工作通常需要的不只是原始速度：多重和重叠坐标轴、带不连续区间的日期时间轴、用于工程标注的注释层、3D Surface 和 2D Contour 绘图，以及让异常永远不会被重采样抹掉的无损渲染。ProEssentials 正是围绕这些需求构建的 — 五个图表对象覆盖 2D、科学 3D、Polar/Smith 和饼图，拥有 1,200 多个属性 — 它也是我们网站上展示的 USGS 水文软件背后的图表引擎。不要只凭“科学”二字就相信；请克隆我们 GitHub 上的行业演示：3D Surface / 2D Contour / 横截面三图同步的材料扫描、油气电缆测井 VDL 水泥胶结测井、超声波井眼成像、真实地形上的 3D 井筒飞越、NEXRAD 多普勒雷达反射率、音频波形示波器，以及实时频谱图热图 — 大多数同时提供 WPF 和 WinForms 项目。如果您的领域在这个列表上，您的评估将从可运行的代码开始，而不是从空白项目开始。

3D 科学图表 →在 GitHub 浏览全部 40 多个仓库 →

ProEssentials 支持 .NET 8 WPF 吗？

是的。ProEssentials v11 提供支持原生 x64 与 ARM64 的 .NET 8 和 .NET 10 程序集，一份完整的 WPF .NET 8 教程能带你在几分钟内从 NuGet 或直接引用出发，做出一张可渲染的图表；.NET Framework 4.8 通过其自己的教程仍获得完整支持，所有目标都由同一个原生引擎驱动。本 FAQ 最初撰写时列在路线图上的内容如今已经交付：基于 .NET 10 的 WinUI 3 已是 v11 中的一等接口。这是一次自然的演进，而非重写——ProEssentials 的内核是原生的，WPF 控件是对该引擎的一层薄封装，因此 WinUI 控件也是另一层薄封装，它用 WinUI 直接的 DXGI swap-chain 呈现替换了 WPF 那套 Direct3D 9 时代的 D3DImage 互操作，从而消除了本页前文所述的合成器桥接。这使 ProEssentials 成为首个构建在原生 C++ 引擎而非托管 XAML 之上的高端 WinUI 图表库。

WPF .NET 8 教程 →WPF .NET Framework 4.8 教程 →

为什么 ProEssentials 不是用 100% 托管代码编写的？

因为我们亲历了“100% 托管”的狂热，并选择了性能而不是流行语 — 而平台如今已回到我们这一边。ProEssentials 已经做了 30 年图表：先是 Win32，然后是 VBX、OCX，最后是 .NET — 当 2000 年代初出现把一切重写为纯托管代码的压力时，我们因坚持让引擎保持原生、只用轻薄的托管接口包装它而受到了真实的批评。托管代码用于按钮、文本框、列表框和网格完全没问题；但对一个高性能渲染引擎来说，重写只会让它变慢，并让它看起来和其他所有托管图表库一样。二十年后，Microsoft 最新的桌面 UI 框架 WinUI 本身就是原生构建的，通过 DXGI 交换链呈现 — 我们当年因坚持而挨批的架构，如今正是平台前进的方向。结果是：一个引擎、三十年积累的正确性，而每个接口 — WPF、WinForms、MFC、Delphi、OCX，以及未来的 WinUI — 都是同一个久经考验的核心之上的轻薄包装。

关于我们的图表（历史）→平台覆盖：两个 API 层 →

最快的 WinForms 图表控件是什么？

在我们公开的测试中，ProEssentials 是我们所知最快的 WinForms 图表路径：一个原生 WinForms 控件，其 Direct3D Compute Shader 引擎直接呈现到窗口的 hDC，在测试硬件上以约 15 毫秒完成 1 亿点的完整无损渲染。帧预算的拆分与其 WPF 同门完全一致 — 数据未变时重绘约 2 毫秒（优化后的顶点和索引缓冲区已在 GPU 上，只需一次绘制调用），数据变化或缩放重新运行过滤着色器时约 15 毫秒，把 1 亿个全新的点搬过总线约 50 毫秒（RTX 3090 上端到端约 15 fps）— 而原生 hDC 路径比同一引擎在 WPF 下测得快约 5%。这个仓库刻意做得极其简单：把竞争对手的图表换进同一个项目，就是真正的比较 — 在您的硬件上，用您自己的眼睛盯着 FPS 计数器。

WinForms 性能与架构 →克隆 WinForms 1 亿点仓库 →

图表方面 WinForms 比 WPF 慢吗？

不慢 — 在同一渲染引擎上，原生 WinForms 控件在我们的测试中比其 WPF 对应物快约 5%。WPF 要求 GPU 输出经过渲染到纹理步骤（D3DImage）并与 WPF 合成器同步，而 WinForms 控件拥有真实的窗口句柄和设备上下文，Direct3D 直接呈现到屏幕。“WinForms 是缓慢的过时选项”这一假设在 GPU 图表上恰好把架构搞反了；完整的测量和方法论见我们的 1 亿点 WinForms 比较。

1 亿点 WinForms 比较 →

SciChart 有原生 WinForms 控件吗？

没有。SciChart 自己的网站声明它不提供原生 WinForms 库，SciChart WPF 通过 Microsoft 的 ElementHost 控件或互操作 API 在 WinForms 应用中使用。这种方式可行，但继承了有文档记载的 WPF/WinForms 互操作限制 — 空域（z 顺序）限制、焦点和鼠标事件问题、一个窗口里两个 UI 框架。ProEssentials 提供真正原生的 WinForms 控件：一个真实的 hWnd，Direct3D 直接向其呈现。

SciChart 的声明（其网站）→

通过 ElementHost 在 WinForms 中承载 WPF 图表有什么问题？

ElementHost 在 WinForms 窗口内嵌入一个 WPF 孤岛，Microsoft 的互操作性文档描述了随之而来的取舍。最著名的是空域规则 — 窗口中的每个像素恰好属于一种技术，因此 WPF 内容无法与 WinForms 控件自由分层或进行透明混合。开发者还会遇到边界处的焦点和鼠标事件差异、横跨两个框架的设计器体验，以及同时携带两套技术栈的部署。对设置对话框来说这些都不致命；但对应用程序的主要高交互图表界面而言，原生控件可以完全避开这条边界。

Microsoft 空域文档 →

DevExpress SwiftPlot 是什么，它的限制是什么？

Swift Plot 是 DevExpress 为 WinForms XtraCharts 提供的快速渲染序列视图，文档面向实时图表和“数万”点及以上的数据集。它通过舍弃功能来换取速度，并要求专用的 SwiftPlotDiagram，无法与同一图表中的其他序列视图组合。它没有 WPF 等价物 — DevExpress 支持工单显示 WPF 客户的变通方案是把 WinForms 控件承载到 WPF 中。作为对照：其文档化的设计目标在数万点量级，而 ProEssentials WinForms 仓库演示的是 1 亿点的无损渲染。

DevExpress Swift Plot 文档 →

Syncfusion 为 WinForms 提供快速/位图序列吗？

Syncfusion 的快速序列类型 — FastLineSeries、FastLineBitmapSeries 及相关位图序列 — 记录在其 WPF、WinUI 和 MAUI 图表控件文档中；其 Windows Forms 图表文档没有列出 FastLine 或位图序列的等价物。Syncfusion 的 WinForms 性能指南转而侧重于禁用视觉功能（样式、阴影、命中测试区域）和用 BeginUpdate/EndUpdate 批量更新。另请注意：WPF 的快速路径是 CPU 位图渲染 — Syncfusion 声明已停止对 DirectX 序列的支持 — 而 Syncfusion 自己的 WPF 基准测试上限为 100 万点。

Syncfusion WinForms 性能指南（其文档）→

MESCIUS ComponentOne FlexChart 适合大型数据集吗？

FlexChart 是 MESCIUS 的 ComponentOne 套件中的图表控件（MESCIUS 即过去的 GrapeCity），该给的认可要给：其公开的性能资料对自身的适用范围异常诚实。厂商自己的 .NET 6 性能研究对 FlexChart 的测试范围是 100 到 30,000 个数据点 — 没有数十亿点的戏码，只有为一款商业图表给出的实测数字：80 多种图表类型、默认 GDI+ 渲染、可选的 DirectX（Direct2D）模式。不过，请把这个范围放到本页的尺度上看：30,000 个点只是上面那些仓库以约 15 毫秒无损渲染的 1 亿个点的 0.03%。对于更大 UI 套件内的仪表盘和报表，FlexChart 是合理的选择；但对于科学、DAQ 或任何以百万计的数据集，套件图表这一类别 — FlexChart、DevExpress、Syncfusion 都一样 — 是错误的工具，上面的渲染架构答案准确解释了原因。

MESCIUS 的 FlexChart 性能研究（其网站）→渲染架构一览 →

TeeChart、Chart FX 或 Nevron Chart 能处理数百万个数据点吗？

Chart FX、TeeChart 和 Nevron 是 Windows 图表领域资历最老的几个名字 — 三者至今仍在积极销售，各自拥有一批忠实的客户：维护着严肃、长寿软件的工程师们；我们尊重这一点，因为这同样描述了我们自己的客户。但读一读它们当前的定位就会发现，大数据渲染根本不是它们竞争的类别：它们的套件横向扩展到了 Web、JavaScript、仪表盘和报表 — Chart FX 强调商业智能和 OLAP，Nevron 提到 GPU 辅助绘制但未公布任何大数据集数字，TeeChart 仍是 Delphi 生态的通用型老牌产品（见下方 Delphi 部分）。Microsoft 内置的 MSChart 也是如此 — 它实际上就是 Microsoft 在 2007 年收购的 Dundas Chart 代码，冻结在 .NET Framework 时代，从未延续到 .NET 5 及以后。这些都不意味着这些组件不好；它们只是通用商业图表 — 如果您的点数停留在几千的量级，没有任何理由迁移。但当构建在它们之上的应用突然需要绘制数百万个样本时，那是架构变更，而不是属性变更 — 由于 ProEssentials 是原生的，并提供旧应用可能基于的每一种接口（WinForms、WPF、MFC、ActiveX/OCX、VCL），它可以接替进来，而不必迫使应用离开自己的框架。

每种接口，同一个原生引擎 →

出处：softwarefx.com · nevron.com · learn.microsoft.com — “Microsoft Chart Control vs. Dundas Chart Control”

如何在 WinForms 应用中绘制高速 ADC/传感器数据？

把采集与渲染分开：在后台线程采集和解析数据，写入预分配的缓冲区，然后让图表在数据到达时渲染，而不是用一个与采样率赛跑的定时器。ProEssentials 直接支持这一模式 — 零拷贝缓冲区意味着没有逐样本分配，内置环形缓冲区在内存不增长的情况下处理滚动窗口，按需渲染对每批新样本恰好绘制一帧。我们公开的 WinForms 环形缓冲区仓库用这条管线实时流式处理 800 万点；数据处理页面记录了相关 API。

数据处理 API →克隆 WinForms 实时仓库 →

WinForms 图表能在嵌入式或低内存 Windows 系统上运行吗？

能。ProEssentials 的可再分发文件约 7 MB — 一到两个文件 — 引擎可在仅 1 GB RAM 的环境中运行；使用纯 DLL 接口时完全不需要 .NET 运行时。按需渲染在这里加倍重要：空闲时不绘制任何东西的图表产生的发热和功耗极小，非常适合无风扇工业面板和 7×24 信息亭。

有面向 C++ / MFC 的高性能图表库吗？

有。ProEssentials 的核心是一个带标准 C API 的原生 Win32 DLL 图表引擎 — 与驱动 WPF 和 WinForms 接口的是同一引擎，包括 Direct3D Compute Shader 渲染。MFC 应用直接调用 PEcreate() 和 PEnset/PEvset 属性函数，整条链路中没有任何 .NET 依赖。如果需求不大，免费选项确实很好：QCustomPlot 在 Qt 应用中广受喜爱，ImPlot 服务于基于 ImGui 的工具 — 两者都不以 GPU 大数据渲染为目标，但在几千个点的量级，它们分文不取且好用。完整的 MFC 教程带您从全新的 Visual Studio C++ 项目做出可工作的图表窗口，产品还会安装一个完整的 MFC 示例项目（C:\ProEssentials11\VC），复现全部 116 个示例。

MFC 图表教程 →

可以在没有任何 .NET 依赖的情况下使用 GPU 加速图表吗？

可以。ProEssentials DLL 接口是纯原生代码：部署只需一到两个文件，共约 7 MB，任何能调用 C API 的语言 — C、C++ 或任何带外部函数接口（FFI）的语言 — 都能驱动完整引擎，包括 GPU Compute Shader。它与 .NET 接口包装的是同一个二进制文件，因此原生路径与托管路径之间没有功能或性能差距。

C++ 最小化图表教程 →

SciChart、Syncfusion 或 DevExpress 的图表能在 MFC C++ 中使用吗？

三家都不提供原生 C++/MFC 或 Win32 DLL 图表库。SciChart 的产品面向 WPF、JavaScript、iOS/macOS、Android 和 Avalonia；Syncfusion 的图表控件面向 .NET 和 Web 框架；DevExpress 提供 .NET 产品线和 Delphi VCL 组件，但没有 MFC/C++ 图表。把任何 .NET 图表承载到 MFC 应用中意味着 CLR 托管或 C++/CLI 包装，并随原生应用一起分发 .NET 运行时。ProEssentials 从相反的方向出发 — 引擎是原生的，.NET 只是它的接口之一。

平台覆盖比较 →

ChartDirector 适合高性能 C++ 图表吗？

ChartDirector 的忠实用户群是靠实力赢来的：完全自包含、无第三方依赖、框架中立（MFC、Qt，甚至无 GUI 的服务器进程）、线程安全，价格只是其他所有商业选项的零头 — 开发者许可 $99，免版税再分发许可 $499。需要做的检查在架构层面：ChartDirector 的文档说图表“可以包含数百万个数据点”，却完全没有公开任何渲染技术 — 整个网站上没有 Direct3D、没有 OpenGL、没有硬件加速的字样 — 也没有公布可用来验证该说法的大数据集耗时。这把它放在通用类别里：对报表、仪表盘和适度的交互图表是极好的性价比，但不是 GPU 无损大数据渲染的竞争者 — 真正参与这个类别的每家厂商都会公布架构和数字。ProEssentials 从相反的一端切入 C++ — Direct3D 计算着色器引擎之上的标准 C API，1 亿点的算术公开且可复现 — 而且同样覆盖无 GUI 用途：调用 PEcreate 时不传父窗口句柄，就得到一个纯内存图表对象，完全无 GUI 地渲染 PNG/JPG，这正是我们 WebForms 接口数十年来使用的机制；若服务器配有 GPU，它还能把计算着色器渲染的图表作为静态图像提供。如果预算说了算、数据集不大，ChartDirector 是个好答案；如果数百万点的实时渲染说了算，架构胜过价格。

ChartDirector for C++（其网站）→

出处：advsofteng.com — “ChartDirector for C++” · advsofteng.com — 购买页面

Delphi 和 C++Builder（VCL）中最快的图表组件是什么？

在我们公开的测试中，ProEssentials 是我们所知最快的 VCL 图表路径：原生 VCL 单元包装着同一个 Direct3D Compute Shader 引擎 — 即在测试硬件上以约 15 毫秒演示 1 亿无损点的那个引擎 — 引擎既不知道也不在乎宿主是 Delphi 还是 C#。这些接口是与时俱进的，不是遗留维护品：v10.0.0.20 为 Builder 13 的现代 Win64x 平台重写了 Embarcadero Builder 接口。教程带您从全新的 Delphi 或 C++Builder 项目做出可工作的图表。

Delphi 图表教程 →C++Builder 图表教程 →

Delphi VCL 中 TeeChart 的高性能替代品是什么？

TeeChart 是实力不俗的老牌产品 — 自 1997 年起与 Delphi 和 RAD Studio 捆绑，对很多图表任务都是合理选择。但它没有瞄准的领域是基于 GPU Compute Shader 的无损大数据渲染：ProEssentials VCL 接口驱动与其 .NET 接口相同的 Direct3D 引擎，把 1 亿点级别的性能带给原生 Delphi 应用，且没有 .NET 依赖。Delphi 教程带您从全新 VCL 项目做出可工作的图表。

Delphi 图表教程 →

Delphi 应用能实时渲染数百万个点吗？

能。ProEssentials VCL 接口把 Delphi 直接连接到原生 Direct3D Compute Shader 引擎，因此渲染上限与公开的 1 亿点仓库所演示的完全相同，并享有同样的零拷贝数据加载和按需渲染模型。产品会安装完整的 Delphi 和 C++Builder 示例项目（C:\ProEssentials11\Delphi 和 \Builder），复现全部 116 个示例 — 示例 115 是与 1 亿点仓库同一设计的实时演示，只是按比例缩小；把它放大到您的采样率就是全部功课。

C++Builder 图表教程 →

可以用真正的图表组件绘制 Access 数据库数据吗（VBA/OCX）？

可以。ProEssentials ActiveX/OCX 接口与 WPF 和 WinForms 接口同步，产品会安装一个完整的 Access 示例数据库 — C:\ProEssentials11\Access\PE11FullDemo.accdb — 复现全部 116 个示例，包括最强的 Direct3D 计算着色器演示，全部在 Access 内运行。有多少项目需要在 Access 数据库里做 GPU 计算着色器图表是个开放问题 — 但看着确实有点不可思议，它运行得很完美，而且需要时它就在那里。F1 上下文帮助可在 VBA 编辑器中使用，v11 AI 代码助手的知识文件覆盖 VBA 工作流，因此 AI 工具可以替您编写 Access 到图表的数据传输代码。MS Access 教程端到端展示了设置过程。

MS Access 图表教程 →

ProEssentials 如何许可 — 按开发者还是免版税？

我们既有按开发者授权，也有面向企业的不限开发者数量授权，且所有情形下的分发都免版税。每一份授权都是永久的，包含全部接口——WinUI、WPF、WinForms、WebForms、ActiveX/OCX、面向 C/C++/MFC 的 DLL，以及 VCL——并且不收取运行时版税、不做逐机激活、也不要求订阅。当前价格见价目表；技术支持免费、不限次数，并由构建引擎的工程师亲自解答，因此授权价格就是全部价格。

价格表 →许可负担比较 →

有免费试用版吗？功能受限吗？

有，而且功能完整 — 评估版就是完整产品，不是功能缩减版。下载即时可用，无需账户或注册，安装结束时的交互式演示会立即展示渲染质量和性能。我们鼓励您在购买前用评估版搭建真实的数据管线；亲手得到的结果比任何比较页面都更有价值 — 包括我们自己的。

下载评估版 →