WPF开发大数量高实时性高的2D绘图功能

Question

WPF C# DirectX wpfc#DirectX

Answer 1

你好 请问有 WPF套用GDI+方法 实现心电图的 code 吗？ 感谢！

Answer 2

WPF会自动使用这个库，而且会自动进行硬件加速。不过最重要地，是任何操作只要有异步调用你就一定要用异步调用方法，而不用同步调用方法。这样通过“整体”才能保证性能——实际上是流畅性，是用户体验比较好。使用了几个同步的、自动阻塞的方法，这是使得绘图程序的显示和操作变“卡”的主要原因。假设有500个地方有这类代码，那么如果你不小心在5个地方使用了同步的、阻塞的方法，就可能恰好整好有一两个方法会让你的程序的用户体验不好了。因此最好是养成“异步编程”的程序设计习惯（但是这很难啊）。

Answer 3

WPF会自动使用这个库，而且会自动进行硬件加速。不过最重要地，是任何操作只要有异步调用你就一定要用异步调用方法，而不用同步调用方法。这样通过“整体”才能保证性能——实际上是流畅性，是用户体验比较好。使用了几个同步的、自动阻塞的方法，这是使得绘图程序的显示和操作变“卡”的主要原因。假设有500个地方有这类代码，那么如果你不小心在5个地方使用了同步的、阻塞的方法，就可能恰好整好有一两个方法会让你的程序的用户体验不好了。因此最好是养成“异步编程”的程序设计习惯（但是这很难啊）。->只要有异步调用你就一定要用异步调用方法
你说的这个有具体的例子吗，比如说扫描函数需要异步调用，或者绘图中的什么步骤是需要异步调用的。

Answer 4

WPF会自动使用这个库，而且会自动进行硬件加速。不过最重要地，是任何操作只要有异步调用你就一定要用异步调用方法，而不用同步调用方法。这样通过“整体”才能保证性能——实际上是流畅性，是用户体验比较好。使用了几个同步的、自动阻塞的方法，这是使得绘图程序的显示和操作变“卡”的主要原因。假设有500个地方有这类代码，那么如果你不小心在5个地方使用了同步的、阻塞的方法，就可能恰好整好有一两个方法会让你的程序的用户体验不好了。因此最好是养成“异步编程”的程序设计习惯（但是这很难啊）。->只要有异步调用你就一定要用异步调用方法
你说的这个有具体的例子吗，比如说扫描函数需要异步调用，或者绘图中的什么步骤是需要异步调用的。比较简单的方式——把绘制和后台数据稍微分离一下，放一个Queue，后台拿到数据都扔进Queue里，前台绘制用一个DispatchTimer，操纵一个DrawingVisual，根据Queue中的数据来进行绘制。我用WPF做出过一个“示波器”程序，大致就是用的这种方式。

Answer 5

WPF会自动使用这个库，而且会自动进行硬件加速。不过最重要地，是任何操作只要有异步调用你就一定要用异步调用方法，而不用同步调用方法。这样通过“整体”才能保证性能——实际上是流畅性，是用户体验比较好。使用了几个同步的、自动阻塞的方法，这是使得绘图程序的显示和操作变“卡”的主要原因。假设有500个地方有这类代码，那么如果你不小心在5个地方使用了同步的、阻塞的方法，就可能恰好整好有一两个方法会让你的程序的用户体验不好了。因此最好是养成“异步编程”的程序设计习惯（但是这很难啊）。->只要有异步调用你就一定要用异步调用方法
你说的这个有具体的例子吗，比如说扫描函数需要异步调用，或者绘图中的什么步骤是需要异步调用的。比较简单的方式——把绘制和后台数据稍微分离一下，放一个Queue，后台拿到数据都扔进Queue里，前台绘制用一个DispatchTimer，操纵一个DrawingVisual，根据Queue中的数据来进行绘制。我用WPF做出过一个“示波器”程序，大致就是用的这种方式。WPF会自动使用这个库，而且会自动进行硬件加速。不过最重要地，是任何操作只要有异步调用你就一定要用异步调用方法，而不用同步调用方法。这样通过“整体”才能保证性能——实际上是流畅性，是用户体验比较好。使用了几个同步的、自动阻塞的方法，这是使得绘图程序的显示和操作变“卡”的主要原因。假设有500个地方有这类代码，那么如果你不小心在5个地方使用了同步的、阻塞的方法，就可能恰好整好有一两个方法会让你的程序的用户体验不好了。因此最好是养成“异步编程”的程序设计习惯（但是这很难啊）。->只要有异步调用你就一定要用异步调用方法
你说的这个有具体的例子吗，比如说扫描函数需要异步调用，或者绘图中的什么步骤是需要异步调用的。比较简单的方式——把绘制和后台数据稍微分离一下，放一个Queue，后台拿到数据都扔进Queue里，前台绘制用一个DispatchTimer，操纵一个DrawingVisual，根据Queue中的数据来进行绘制。我用WPF做出过一个“示波器”程序，大致就是用的这种方式。
感谢参与讨论，您说的这个方法，我也使用过，后来发现DispatchTimer优先级低，改启线程然后调用Invoke。基本可以满足需求，但是UI线程就一个，我们还有别的控件也会抢UI线程的资源，最少有3个线程去同时Invoke到UI线程Render，所以性能越来越差了，这两天研究发现SlimDX 是为c#准备，也支持x64。之前用MDX试过觉得性能还可以，所以想使用DX替换原来的GDI+.