Ultra fast drawing in DotNET

views:

1088

answers:

+4 Q:

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

+3 A:

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.

rein 2009-06-27 19:50:36

Unfortunately it is important that the entire particle cloud is visible at the same time. When the user zooms in I can discard many of the particles (they are stored in OcTrees and 2D grids so that part is easy), but it has to work well for a fully zoomed out view as well.Is it possible to use both GDI+ and -say- DirectX on the same memory bitmap, or will I lose precious milliseconds blitting pixels between these two SDKs?

David Rutten 2009-06-27 19:56:36

I wouldn't think it's possible to use GDI+ and DirectX on the same memory bitmap - the one is rendered by the graphics card, the other by software. You can draw GDI+ to the same hWnd as what you're drawing DirectX onto but synchronizing them can be a little difficult.

rein 2009-06-27 20:00:28

+2 A:

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?

JaredPar 2009-06-27 19:52:06

I've thrown all optimisations at this code I'm aware off, but I have never been able to properly profile display code. I find that when I add profiling to performance sensitive code I always end up changing the actual performance (I think particle physicists have been struggling with similar problems).The full-screen drawing is not an issue. If I only render a few particles, the refresh rate is very acceptable.I've tried to render particles as filled ellipses, as a single GraphicsPath and using DrawBitmap with sprites that have the exactly correct pixel-depth and resolution.

David Rutten 2009-06-27 20:02:40

@David-Rutten: Did you ever get this resolved? Reading your comment, I have to say please don't expect your profiling not to slow it down. *That doesn't matter.* What matters is percent time in each routine or line of code, because that is what would be saved if that routine or line of code were not there. By time I mean *wall-clock time*. If sampling is restricted to in-thread CPU time, it will be blind to system calls that can take a lot of time.

Mike Dunlavey 2010-03-08 01:56:01

@Mike: I haven't been able to satisfactory solve this in GDI+. Degrading the display during dynamic redraws seems to be the only solution I could wrap my head around. I'm looking at GTK+ now, but my job has gotten the better of me lately and I've switched from UI code back to core development.

David Rutten 2010-03-08 02:20:37

+1 A:

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.

Michael Stum 2009-06-27 19:58:58

I haven't yet, but I will now. Thanks for the tip.I've been using DotNET2.0 so far but there's no reason why I can't switch.

David Rutten 2009-06-27 20:03:58

+3 A:

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.

Rob van Bentem 2009-06-27 20:05:08

Be aware that with earlier versions of XNA it was quite hard to mix WinForms applications with XNA. As far as I know, this is now supported.

rein 2009-06-27 20:07:52

You guys are golden! Thanks so much. I'll be busy for a week or so trying all this stuff out.

David Rutten 2009-06-27 20:09:39

+1 A:

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.

Jules 2009-06-28 14:26:26

+2 A:

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.

Mike Dunlavey 2009-06-29 02:17:22

ansaurus

tags:

views:

answers:

Ultra fast drawing in DotNET

related questions