DotNET 中的超快速绘图
初步测试表明 GDI+（用 VB.NET 编写）对于我的目的来说不够快。 我的应用程序需要能够以每秒 20 帧以上的速度以全屏分辨率绘制数万个粒子（彩色圆圈，最好是抗锯齿的）。
我对放弃 GDI+ 犹豫不决，因为我还需要 GDI+ 的许多其他高级绘图功能（虚线图案、图像、文本、路径、填充）。
寻找有关使用 OpenGL、DirectX 或其他平台加速 VB.NET 内的粒子渲染的好建议。 我的应用程序是严格的 2D。
善意， 大卫
Initial tests indicate that GDI+ (writing in VB.NET) is not fast enough for my purposes. My application needs to be able to draw tens of thousands of particles (coloured circles, very preferably anti-aliased) in a full screen resolution at 20+ frames per second.
I'm hesitant to step away from GDI+ since I also require many of the other advanced drawing features (dash patterns, images, text, paths, fills) of GDI+.
Looking for good advice about using OpenGL, DirectX or other platforms to speed up particle rendering from within VB.NET. My app is strictly 2D.
Goodwill,
David
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
当您使用 VB.net 时，您是否尝试过使用 WPF（自 3.0 起成为 .net 的一部分）？ 由于 WPF 基于 DirectX 而不是 GDI+，因此应该能够为您提供所需的速度，尽管开发 WPF 并不简单。
As you're working in VB.net, have you tried using WPF (Part of .net since 3.0)? As WPF is based on DirectX rather than GDI+, that should give you the speed you need, although developing WPF is not straight-forward at all.
因为GDI+不被显卡移动，所以渲染速度很慢，因为它使用CPU来渲染。 至少，您可以使用 DirectX 或 SlimDX。
（抱歉英语不好）
请参阅：http://msdn.microsoft.com/en-us/library/windows/desktop/ff729480%28v=vs.85%29.aspx
http://www.codeproject.com/Articles/159586 /启动-DirectX-with-Visual-Basic-NET
Because the GDI+ is not moved by the graphics card, it's slow to render because it uses the CPU to render. At least, you can use DirectX or SlimDX.
(sorry for bad english)
See This: http://msdn.microsoft.com/en-us/library/windows/desktop/ff729480%28v=vs.85%29.aspx
http://www.codeproject.com/Articles/159586/Starting-DirectX-with-Visual-Basic-NET
如果您想使用 VB.NET，那么您可以使用 XNA 或 SlimDX。
我有一些使用 GDI+ 和 XNA 制作游戏的经验，我可以理解 GDI+ 给你带来了麻烦。
如果我在你那里我会检查 XNA，它比 GDI+ 快得多，因为它实际上使用你的视频卡进行绘图，并且它有很多很好的在线文档和示例。
SlimDX 看起来也不错，但我没有任何使用经验。 SlimDX 基本上是.NET 的 DirectX API。
If you want to use VB.NET, then you can go with XNA or SlimDX.
I have some experience in creating games with GDI+ and XNA, and I can understand that GDI+ is giving you trouble.
If I where you I'd check out XNA, it's much faster than GDI+ because it actually uses your video card for drawing and it has a lot of good documentation and examples online.
SlimDX also looks good but I don't have any experience with it. SlimDX is basically the DirectX API for .NET.
获得所需速度的唯一方法是从软件渲染转向硬件渲染……不幸的是，这确实意味着转向 OpenGL 或 DirectX。
另一种方法是尝试优化图形例程，以仅绘制需要绘制的粒子，而不是整个屏幕/窗口。
我同意 JaredPar 的观点，即在大规模切换到新框架之前，最好首先进行分析，以确定是否可以改进现有的代码库。 如果您不熟悉 DirectX，那么它并不是最简单的框架。
The only way to get the speed you need is to move away from software rendering to hardware rendering... and unfortunately that does mean moving to OpenGL or DirectX.
The alternative is to try and optimise your graphics routines to only draw the particles that need to be drawn, not the whole screen/window.
I would agree with JaredPar that you're better off profiling first to determine if your existing codebase can be improved before making a huge switch to a new framework. DirectX is not the easiest framework if you're unfamiliar with it.
在使用 GDI+ 编写游戏制作器时，我发现最显着的速度提升是将我的位图转换为 Format32bppPArgb；-
SuperFastBitmap = ConvertImagePixelFormat(SlowBitmap, Imaging.PixelFormat.Format32bppPArgb)
如果它们还不是这种格式，您会看到转换后立即产生差异。
The most significant speed increase I found, when writing a game maker with GDI+, was to convert my bitmaps to Format32bppPArgb;-
SuperFastBitmap = ConvertImagePixelFormat(SlowBitmap, Imaging.PixelFormat.Format32bppPArgb)
If they are not in this format already, you'll see the difference immediately when you convert.
问题可能出在您的算法中，而不是 GDI+ 中。 分析是唯一确定的方法。 如果没有配置文件，您很可能会切换到新的 GUI 框架并遇到完全相同的问题。
如果您进行了分析，GDI+ 的哪一部分导致了问题？
It's possible the problem is in your algorithm and not GDI+. Profiling is the only way to know for sure. Without a profile it's very possible you will switch to a new GUI framework and hit the exact same problems.
If you did profile, what part of GDI+ was causing a problem?
正如贾里德所说，
可能您的周期中有很大一部分没有进入 GDI，您也许可以减少这些周期。
找到这些的一个简单方法是随机停止几次并检查堆栈。 你在浪费时间的行为中抓住它的机会等于被浪费的时间的比例。
任何出现在多个此类示例中的指令或调用指令，如果您可以替换它，您将看到加速。
一般来说，方法是这样的。
As Jared said,
it could be that a significant fraction of your cycles are not going into GDI, and you might be able to reduce those.
A simple way to find those is to halt it at random a few times and examine the stack. The chance that you will catch it in the act of wasting time is equal to the fraction of time being wasted.
Any instruction or call instruction that appears on more than one such sample is something that, if you could replace it, you would see a speedup.
In general, the method is this.