在DotNET中进行超快速绘制

初步测试表明，GDI +（用VB.NET编写）对于我的目的来说速度不够快。我的应用程序需要能够以每秒20帧以上的全屏分辨率绘制数以万计的粒子（彩色圆圈，最好是消除锯齿）。在DotNET中进行超快速绘制

因为我还需要许多GDI +的其他高级绘图功能（破折号图案，图像，文本，路径，填充），所以我很犹豫是否会退出GDI +。

寻找有关使用OpenGL，DirectX或其他平台加速VB.NET中的粒子渲染的好建议。我的应用程序严格为2D。

商誉，大卫

来源

2009-06-27 David Rutten

如果你想使用VB.NET，那么你可以使用XNA或SlimDX。

我在使用GDI +和XNA创建游戏方面有一些经验，我可以理解GDI +给你带来麻烦。如果我在哪里查看XNA，它比GDI +快得多，因为它实际上使用了您的视频卡进行绘图，并且它在网上有很多很好的文档和示例。

SlimDX看起来不错，但我没有任何经验。 SlimDX基本上是.NET的DirectX API。

来源

2009-06-27 20:05:08

得到你所需要的速度，唯一的方法是从软件渲染搬往硬件渲染......不幸的是，它意味着移动到OpenGL或DirectX。

另一种方法是尝试优化图形例程以仅绘制需要绘制的粒子，而不是整个屏幕/窗口。

我同意JaredPar的观点，你最好先分析一下，以确定你现有的代码库是否可以在巨大转换到新框架之前得到改进。如果你不熟悉DirectX，它并不是最简单的框架。

来源

2009-06-27 19:50:36 rein

不幸的是，重要的是，整个粒子云是在同一时间可见。当用户放大时，我可以丢弃许多粒子（它们存储在OcTrees和2D网格中，因此部分很容易），但它也必须适用于完全缩小的视图。是否可以在同一个内存位图上同时使用GDI +和-say- DirectX，或者我会在这两个SDK之间丢失宝贵的毫秒级像素吗？ – 2009-06-27 19:56:36

我不认为可以在同一个内存位图上使用GDI +和DirectX - 一个是由图形卡渲染的，另一个是由软件渲染的。您可以将GDI +绘制到与DirectX相同的hWnd上，但同步它们会有点困难。 – rein 2009-06-27 20:00:28

这是可能的问题是在你的算法，而不是GDI +。分析是确定知道的唯一方法。如果没有配置文件，您很可能会切换到新的GUI框架并遇到完全相同的问题。

如果你做过配置文件，GDI +的哪个部分导致了问题？

来源

2009-06-27 19:52:06 JaredPar

我已经抛弃了这个代码的所有优化，我知道了，但我从来没有能够正确配置显示代码。我发现，当我将性能敏感代码添加到性能分析时，我总是最终改变实际性能（我认为粒子物理学家一直在为类似问题而苦苦挣扎）。全屏幕绘图不是问题。如果我只渲染一些粒子，刷新率是非常可以接受的。我试图渲染粒子作为填充椭圆，作为一个单独的GraphicsPath和使用DrawBitmap与具有完全正确的像素深度和分辨率的精灵。 – 2009-06-27 20:02:40

@ David-Rutten：你有没有解决这个问题？阅读你的评论，我不得不说，请不要指望你的描述不要放慢速度。 *这并不重要。*重要的是每个例程或代码行中的时间百分比，因为如果该例程或代码行不在那里，将会节省多少时间。到时候我的意思是*挂钟时间*。如果采样限制在线程CPU时间内，那么系统调用将会花费很多时间。 – 2010-03-08 01:56:01

@Mike：我还没有能够满意地解决这个在GDI +。在动态重绘期间降级显示器似乎是我可以包裹头部的唯一解决方案。我现在在看GTK +，但最近我的工作变得越来越好，我已经从UI代码切换回了核心开发。 – 2010-03-08 02:20:37

当你在VB.net工作，你有没有尝试过使用WPF（自3.0的.net部分）？由于WPF基于DirectX而不是GDI +，它应该能够提供您所需的速度，尽管开发WPF并不是直截了当的。

来源

2009-06-27 19:58:58