WPF能否在性能敏感的环境中渲染具有300000个点的线路径？

一个简单的XY线图：X轴代表可能的评级百分比的完整范围，从一端的0%到另一端的100%。具体而言，X值将代表我们的评级截止值，或交易在不再可接受之前的最低评级。Y轴将显示从0到已通过的事务总数的值。Y值将表示评级大于当前X值（或大于或等于当前X值，我尚未决定）的交易总数。第一次绘制此图时，没有事务，因此该图将从“y=0x”开始

假设第一笔交易成功，评级为40%。交易评级表明，如果我们的评级截止值低于40%，则该交易是可接受的。（…或小于或等于40%。同样，我还没有决定）

首先，Y轴将重新缩放以显示0-1的范围（因为1是事务总数）。然后，该行将被修改，以指示0个事务在x=40或更多时是可接受的，1个事务在x=40或更少时是可接受的。在WPF中，只需在直线路径上添加两个点（一个在（40,0）处，另一个在（40,1）处），然后将直线的左端点移动到（0,1），即可轻松实现这一点。直线的右端点将保持在（100,0）。然后可以对第二个事务重复此过程，依此类推

---

问题是我们将处理六位数的交易量。我想确保我在最大程度上使用WPF的硬件加速矢量绘制功能，以确保图形在试图在单线路径上渲染300000个点时不会延迟或冻结程序的其余部分。或者WPF应该能够在心跳中处理这样的数字吗？我需要找到一种方法来实现这个图，而不会使应用程序停止。我相信WPF的矢量绘图平台将提供一个解决方案，但我对如何利用WPF知之甚少，无法确定我是否充分利用了WPF的高性能渲染功能。

如果您不使用.NET 3.5 SP1，请不要使用任何着色器效果。否则，WPF开发人员将无法确保它使用硬件加速。

我不知道答案，但编写一个快速测试所需的时间不会比您发布测试所需的时间长太多。另外，有关类似的讨论，请参见。

如果您希望速度更快，最好的方法是从控件派生并实现OnRender-通常这不是必需的，但对于您的应用程序来说可能是必需的

---

也让我们后退一步——你现在渲染的屏幕肯定不是300 K像素。在开始渲染之前，通过将n个节点平均化为一个节点来减少缓冲区，直到得到更接近实际设备分辨率的东西，然后在屏幕上绘制。可能值得一看库。我最近一直在使用它，对大量数据没有任何问题。它只是一个早期版本（实际上是0.3版），所以没有太多文档，但它确实有一些示例演示如何使用它。希望这足以让你开始

---

SimulationSample生成大量数据，因此这应该是一个很好的起点。

我刚刚偶然发现了这篇文章，我自己正在构建一个线条图控件，当我们实时更新线条上的点时，它需要非常高的性能

如果你追求的是视觉效果和数量我怀疑您会发现一种比直接针对WPF的可视层编程更高效的方法（链接：，）。我使用这种方法的初步结果是非常积极的

这将比重写OnRender更具性能，因为它将鼓励您利用WPF的保留模式绘图子系统（所有绘图指令都缓存在该子系统中）

也就是说，如果需要更新的只是直线上的一个点，则更新该点将强制直线视觉更新，但不会强制图形的其余部分（轴、网格线等）更新。。。因为这些图纸说明将被保留并重新使用（因为它们不会更新）

在Matthew MacDonald的第14章中，有一个关于WPF可视层编程的伟大章节（标题为“视觉”）。第2章的第13页也有一节，他讨论了绘图可视化方法如何完美地应用于图表组件。最后，他写了一本MSDN杂志，其中散点图的最佳整体解决方案是绘图可视化方法

---

（现在，我知道你的问题提到轴也将更新…因此我的答案是针对一般情况…但我仍然认为这种方法将是最有效的…因为只有需要更新的东西…才会更新。）

IMHO，Paul似乎已经走上正轨，请查看地图平滑部分，一些例子使用佛罗里达2000年选举结果（约900万张选票和1800万总人口）作为数据集

按照AgileJon的思路，如果没有直接的技术可以更好地依赖您的数据集，我会使用简单的手动发出位图。我呈现了散点图的可视化效果，这些散点图在几秒钟内很容易达到1600000（1600万+），完整的32位ARGB托盘

你似乎说过“但回到位图似乎是一个巨大的倒退”，我不会这么快说，宇宙受到物理极限的限制

---

我引用了另一篇关于codeproject的文章，这篇文章做了成千上万的3D绘图和动画等。

好的。但这样的工作量对它来说太大了吗？我的意思是，渲染一个有这么多点的模型比我在（尽管有限）建模中看到的要多得多