Ultra fast drawing in DotNET

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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?

Answer 5

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.

Answer 6

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.