David Rutten
David Rutten

Reputation: 4806

Ultra fast drawing in DotNET

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

Upvotes: 6

Views: 9197

Answers (7)

Guest
Guest

Reputation: 1

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

Upvotes: 0

Mike Dunlavey
Mike Dunlavey

Reputation: 40649

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.

Upvotes: 2

Jules
Jules

Reputation: 4339

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.

Upvotes: 3

Rob van Bentem
Rob van Bentem

Reputation: 94

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.

Upvotes: 5

Michael Stum
Michael Stum

Reputation: 180874

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.

Upvotes: 1

rein
rein

Reputation: 33445

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.

Upvotes: 3

JaredPar
JaredPar

Reputation: 754525

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?

Upvotes: 2

Related Questions