WPF 能否在性能敏感的环境中渲染包含 300,000 个点的线条路径？
一个简单的 XY 线图：X 轴将代表可能的评级百分比的完整范围，从一端的 0% 到另一端的 100%。 具体来说，X 值将代表我们的评级截止值，或者交易在不再可接受之前可以具有的最低评级。 Y 轴将显示从 0 到已完成的交易总数的值。 Y值将代表评级大于当前X值（或大于或等于当前X值，我还没有决定）的交易总数。 首次绘制此图时，不会发生任何事务，因此该图将从“y=0x”开始。
假设第一笔交易成功，评级为 40%。 该交易的评级表明，如果我们的评级截止值低于 40%，则该交易是可以接受的。 （...或者小于或等于 40%。再说一次，我还没有决定）。
首先，Y 轴将重新缩放以显示 0-1 的范围（因为 1 是交易总数）。 然后，该行将被修改，以指示 x=40 或以上可接受 0 个交易，x=40 或以下可接受 1 个交易。 在 WPF 中，这很容易实现，只需将两个点添加到线条路径 - 一个位于 (40,0)，另一个位于 (40,1) - 然后将线条的左端点移动到 (0,1)。 线的右端点将保持在 (100,0)。 然后可以对第二笔交易重复此过程，依此类推。
问题是我们将处理六位数的交易量。 我想确保我最大限度地使用 WPF 的硬件加速矢量绘图功能，以确保图形在尝试将 300,000 个点渲染到单线路径上时不会滞后或冻结程序的其余部分。 或者 WPF 是否应该能够立即处理这样的数字？ 我需要找到一种方法来实现该图，而又不会减慢应用程序的速度。 我相信 WPF 的矢量绘图平台将提供一个解决方案，但我对如何利用 WPF 的了解还不够，无法确定我是否能充分利用 WPF 的高性能渲染功能。
A simple XY line graph: The X axis will represent the complete range of possible rating percentages, from 0% on one end to 100% on the other. Specifically, the X value will represent our rating cut-off, or the minimum rating a transaction can have before it is no longer acceptable. The Y axis will show values from 0 to the total number of transactions that have come through. The Y value will represent the total number of transactions that have a rating greater than the current X value (or greater than or equal to the current X value, I haven't decided yet). No transactions will have come through when this graph is first drawn, so the graph will begin at "y=0x".
Let's say the first transaction comes through, with a rating of 40%. The rating of the transaction indicates that this transaction is acceptable if our rating cut-off is less than 40%. (... or less than or equal to 40%. Again, I haven't decided yet).
First, the Y axis will rescale to show the range of 0-1 (since 1 is the total number of transactions). Then the line will be modified to indicate that 0 transactions are acceptable from x=40 or more, and that 1 transaction is acceptable from x=40 or less. This is easy to accomplish in WPF by simply adding two points to the line path - one at (40,0) and the other at (40,1) - and then moving the line's left endpoint to (0,1). The line's right endpoint will remain at (100,0). This process can then be repeated for the second transaction, and so on.
The problem is that we will be dealing with six-digit quantities of transactions. and I want to make sure I am using WPF's hardware accelerated vector drawing capabilities to their fullest extent to ensure the graph doesn’t lag or freeze the rest of the program as it tries to render 300,000 points onto a single line path. Or is WPF supposed to be able to handle numbers like that in a heartbeat? I need to find a way to implement this graph without slowing the application to a halt. I have faith that WPF's vector drawing platform will provide a solution, but I don't know enough about how to exploit WPF to be certain that I am getting the most out of WPF's high-performance rendering capabilities.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我刚刚偶然发现了这篇文章，并且正在自己构建一个折线图控件，当我们实时更新线上的点时，该控件需要非常高性能。
如果性能和 Visual 数量是您所追求的...我怀疑您会找到比直接针对 WPF 的 Visual 层进行编程更具性能的方法（链接：1, 2)。 我使用这种方法的初步结果非常积极。
这将比重写 OnRender 性能更高，因为它将鼓励您利用 WPF 的保留模式绘图子系统（其中缓存了所有绘图指令）。
也就是说，如果您需要更新的只是线上的一个点，那么更新该点将强制线 Visual 更新，但不会强制图形的其余部分（轴、网格线等）更新..因为这些的绘图说明被保留并将被重复使用（因为它们没有更新）。
Matthew 的 Pro WPF in C# 2008 第 14 章MacDonald 有一个很棒的章节（标题为“Visuals”），介绍了针对 WPF 的可视层进行编程。 WPF Control Development Unleashed 的第 2 章也有部分在第 13 页，他讨论了 DrawingVisual 方法如何完美地用于图表组件。 最后，Charles Petzold 撰写了一本 MSDN 杂志文章 其中散点图的最佳整体解决方案是 DrawingVisual 方法。
（现在，我知道你的问题提到轴也将更新......所以我的答案确实适用于一般情况......但我仍然认为这种方法将是最有效的......作为只有需要更新的东西......才会更新。）
I just stumbled upon this post and am building a line graph control myself that needs to be very performant as we update the points on our lines in a real-time manner.
If performance and number of Visual(s) are what you are after ... I doubt you will find a more performant approach than programming directly against WPF's Visual layer (links: 1, 2). My initial results from using this approach have been very positive.
This will be even more performant than overriding OnRender as it will encourage you to take advantage of WPF's retained mode drawing subsystem (where all the drawing instructions are cached).
That is, if all you have to update is a point on the line, then updating the point will force the line Visual to update but won't force the rest of the graph (axes, gridlines, ...) to update ... as the drawing instructions for these are retained and will be reused (since they aren't updating).
Chapter 14 in Pro WPF in C# 2008 by Matthew MacDonald has a great section (titled 'Visuals') on programming against WPF's Visual layer. Chapter 2 of WPF Control Development Unleashed also has section on page 13 where he discusses how a DrawingVisual approach would be perfect for a charting component. Finally, Charles Petzold wrote a MSDN Magazine article where the best overall solution to a scatter plot was a DrawingVisual approach.
(Now, I know that your question mentioned the axes will also be updating ... and so my answer is really for the general case ... but I still think that this approach will be the most performant ... as only the things that need updating ... will update.)
如果您希望它更快，最好的方法是从 Control 派生并实现 OnRender - 通常这不是必需的，但对于您的应用程序来说可能是必需的。
另外，让我们退后一步 - 您渲染的屏幕肯定不是 30 万像素； 在进行渲染之前，通过将 n 个节点平均为一个节点来减少缓冲区，直到获得更接近实际设备分辨率的值，然后将其绘制在屏幕上。
If you want it to be fast, the best way is to derive from Control and implement OnRender - normally this isn't necessary, but for your application it might be.
Also, let's take a step back - the screen you're rendering to certainly isn't 300k pixels across; before you go to render, reduce the buffer by averaging n nodes into one until you've got something closer to the resolution of the actual device, then draw it on-screen.
我不知道答案，但是编写快速测试的时间不会比您发布的时间长。 另请参阅此线程类似的讨论。
I do not know the answer, but coding up a quick test shouldn't take much longer than it did for you to post. Also, see this thread for a similar discussion.
可能值得一看 WPF DynamicDataDisplay 库。 我最近一直在使用它，在处理大量数据时没有任何问题。 它只是一个早期版本（实际上是 0.3），因此没有太多文档，但它确实有示例展示如何使用它。 希望这足以让您开始。
SimulationSample 会生成大量数据，因此这应该是一个很好的起点。
It might be worth having a look at the WPF DynamicDataDisplay library. I've been using it recently and haven't any problems with large amounts of data. It's only an early version (0.3 in fact) so there's not much documentation, but it does have samples showing how to use it. Hopefully that'll be enough to get you started.
The SimulationSample generates lots of data, so that should be a good place to start.
如果您不使用 .NET 3.5 SP1，请不要使用任何着色器效果。 否则，作为 WPF 开发人员您不需要做太多事情以确保它使用硬件加速。
If you aren't using .NET 3.5 SP1 just don't use any of the shader effects. Otherwise there isn't much you need to do as a WPF developer to ensure it uses hardware acceleration.
恕我直言，保罗似乎走在正确轨道上，检查一下在地图平滑部分中，一些示例使用佛罗里达州 2000 年选举结果（约 900 万张选票，总共 18+M 人）作为数据集。
沿着 AgileJon 的线索，如果没有直接的技术可以更好地描述您的数据集，我会简单地手动发出位图。 我在几秒钟内渲染了散点图的可视化，很容易达到 16 000 000（1600 万+），完整的 32 位 ARGB 调色板。
您似乎说过“但是回到位图似乎是一个巨大的倒退”，我不会那么快地说，宇宙受到物理限制。
我将另一篇文章提到了 这篇 codeproject 文章，该文章做了数以万计的3D绘图+动画等...
IMHO, Paul seems to be on the right track, check out the sections on map smoothing, some of the examples use results from the Florida 2000 election results (~9M votes 18+M total people) for data sets.
Along the lines of the thread from AgileJon, somewhat, I would use simply manually emit a bitmap if no straight forward technique was available to better depect your data set. I render visualizations of scatter plots that are easially 16 000 000 (16 Million+) in seconds, full 32bit ARGB pallette.
You seem to of remarked "But going back to bitmaps seems like a giant step backwards", I would not be so quick to say that, the universe is bound by physical limits.
I referred another post to this codeproject article, which does many tens of thousands of 3D plots + animation etc...