GDI+ 1.0 vs GDI+ 1.1

[wyrd]

Does anyone know if GDI+ in .NET framework version 1.1 has any performance increases over the 1.0 version?

 

I'm only getting 28 fps when drawing 300 to 336 32x32 images on the screen. I need it to go faster. No, using DirectDraw is not an option! :D Neither is the Windows API. :P

[aewarnick]

One thing that I found makes drawing the images faster is using your own double bufffering instead of default. And (I didn't try this) you could handle the WndProc directly and that should probably be the fastest.

[wyrd]

From numerous threads, I've read that it's recommonded you use a forms SetStyles, and do all of your drawing inside the Paint event. This is contradictory to your suggestion about using my own double buffering.

 

Did I misunderstand something?

[ThePentiumGuy]

i dont think you did, u can do double buffering even with drawing inside the paint event:

 

in form1.load

setstyle(controlstyles.doublebuffering,true)

[aewarnick]

Actually on second examination, I found that I used the windows api to do this but I manually double buffed instead of automatic and it was much faster that way. What I mean is that I used SetStyle to double buff, drew with the api and then tried double buffing manually and found that manual double buffing is much faster.

 

But forget that, you said you did not want to use the windows api. PentiumGuy, it would be better to put startup objects in the Form's constructor instead of in Load() I think. For some things, however, Load() is the only startup method that will work right. But for most that is what the Constructor is designed to do (Where InitializeComponent is).

 

Have you used DrawImageUnscaled instead of DrawImage?

Another thing you can do is override the OnPaintBackground event and do nothing there. But you probably don't want to do that.

 

I have really exhaused all options in using GDI+ for drawing images. I don't think it gets any better. Maybe try lowering the Bpp of the images after they are declared.

Edited August 2, 2003 by aewarnick

[wyrd]

Ah.. yeah Windows API is faster then GDI+. Hopefully they'll speed up GDI+ in future releases so it'll be closer in performance to the Windows API drawing functions.

 

DrawImageUnscaled looks interesting. I'm drawing images using TextureBrush though (it's faster then DrawImage), but I'll give DrawImageUnscaled a shot.. just for the heck of it.

[Volte]

I doubt they'll ever catch up to the raw speed of API, but the extreme ease and flexibility of GDI+ makes it worth the small performance hit (in many cases). If you are really serious about speed, DX9 is the best route.

[wyrd]

With the games I'm making, speed isn't to much of an issue (so long as I can keep it around 25 FPS it's all good). I can solve the current problem by using a smaller display area to draw a smaller map (less tiles). I suppose at some point I'll need to get down and dirty with DirectDraw and then eventually DirectX.

[Volte]

DirectDraw is part of DirectX. :)

[wyrd]

Well yes, but DD is 2d, while DX forces you to use 3d. I consider them different. :)

[PlausiblyDamp]

DD is just a means of getting things on Screen Direct3D is the 3d stuff. (I think)

[mutant]

Well yes, but DD is 2d, while DX forces you to use 3d. I consider them different. :)

 

DirectX doesnt force you to use 3D. You can use DirectDraw for 2D, Direct3D for 3D and APIs like DirectSound for sound or DirectInput for input. All of those are based on DX and are part of, not only 3D :).

:)

[aewarnick]

Does textureBrush support transparency at all. If it doesn't you might as well use BitBlt.

[mutant]

Yeah it does, becuase you have to pass in an object of Image type to the brush, so you can pass in Bitmap object which you made transparent using MakeTransparent.

[aewarnick]

Then it is probably the same speed as DrawImageUnscaled.

[Volte]

It's not. I've tested. The API is much faster (for simple operations at least). I drew 2000 pictures on the form with GDI+ and it took like 500ms, and the same with GDI32 took about 200ms. However, in a real game situation with texturebrushes, solidbrushes, bitmaps, text, and the whole bit being rapidly drawn on the screen, it's possible the speed gap would get smaller or disappear. I'm not totally sure how GDI32 scales to meet larger tasks.

 

However, the capabilities of GDI+ and the GDI+ objects in general (even just the fact that there are real GDI+ objects) made it totally worth it for most situations.

[wyrd]

DirectX doesnt force you to use 3D. You can use DirectDraw for 2D, Direct3D for 3D and APIs like DirectSound for sound or DirectInput for input. All of those are based on DX and are part of, not only 3D :).

:)

 

Alright.. you got me there. :P I always seem to intermix DirectX w/ Direct3D. Perhaps I should stop doing that.

 

Yeah it does, becuase you have to pass in an object of Image type to the brush, so you can pass in Bitmap object which you made transparent using MakeTransparent.

 

As far as I know TextureBrush doesn't support transparency (which is why it draws faster then DrawImage). But since I've been wrong about everything else.. I just don't know anymore. :P

[mutant]

It does, before passing in the Bitmap object to the TextureBrush use this:

BitmapObject.MakeTransparent(Color to make transparent)

:)

[wyrd]

Strange. Maybe I made a typo when I tested it. Or maybe I didn't test it? I need a catscan...

[Volte]

Just to clarify:

 

DirectX is a package of other smaller libraries, such as DirectDraw, DirectSound, DirectMusic, DirectInput, and Direct3D. When you use any of those, you are using DirectX.

[aewarnick]

Yes, I knew that BitBlt was faster but I was talking about DrawImageUnscaled and the TextureBrush being the same speed probably.

[Nerseus]

I ran my own tests and confirmed what wyrd is seeing. I draw roughly 330 32x32 rectangles with DrawImage and I only get about 30 FPS. I create the Graphics object outside of the main loop. Inside the loop I do a few small calculations (maybe 4 multiplications) and use a double loop to call DrawImage.

 

I only call DoEvents once a second (after the FPS is calculated) to minimize extra time.

 

If you make the form bigger, it slows down even more.

 

My machine is a P4 1.69 Ghz with 1.5 gig memory and a Radeon 9500 Pro (rocks!). I haven't tried using BitBlt in C# yet, but I know that in VB6 days I'd get something crazy like 300 or 400 FPS.

 

I've attached the TEST project. Don't flame me on the code, only took 1.25 hours to write :)

 

-nerseus

drawtest1.zip

[Derek Stone]

I get roughly 140 FPS running your example Nerseus. Don't I feel special. :)

[Nerseus]

*wonders what size the form was when I zipped it up :)*

 

It will change the amount of tiles drawn based on the Form's size. I originally had the form starting out maximized but I didn't like that, not one little bit (FAR too slow) :)

 

-nerseus

[Volte]

I get 115 on my GeForce 3. :)

 

However, at fullscreen, it drops to 9.