the use of picture boxes and .gif form objects vs. java-style paint() and draw(): which is better?

hi everyone. i'm currently pursuing my thesis, which is in its early stages. for our early game prototype (an RPG in the vein of ultima) we used picture boxes and a custom .dll to allow the use of animated GIF files in the same way as normal JPEGS and BMPS. however, the system functioned particularly slowly without us having any idea why. we also stumbled upon a tutorial on .NET's ThreadPool stuff that reminded us of Java paint and repaint methods used in graphical applications. for the length of time we have on our hands, either this or the use of the previously mentioned form objects is the way to go. we'd like to know which is better to solve the speed issue? what could be the possible cause for the slowness of the graphics? any possible solutions? thanks. :)

The problem is not in your programming, but in the nature of the System.Drawing library. Forms use GDI+, a drawing API which is naturally slow and not designed for use in games. The cause of the slowness is due to GDI+'s noticeable and inherent sluggishness in the complexity of the routines used by the library as well as the high level of abstraction, an issue that cannot be avoided when it comes to working with graphics in forms. You can remedy this somewhat by using the Graphics.DrawImageUnscaled method to draw an Image directly onto the Form's client area. As animated GIFs contain frame rates varying from 0 to some neglegibly large number of milliseconds, GDI+ is simply not suited to do the job for any frame shown for less than 50 milliseconds. ThreadPools are just alternatives to normal threading, which will not fix any problems when the drawing routines themselves are too slow. The best solution involves not using the default drawing routines, but rather an API that is better suited towards animation: Managed DirectX operates at a much lower level of abstraction and makes use of certain optimizations like drawing routines written in assembly, and thus performs drawing routines at much higher speeds (in the case of animated GIFs, as quickly as your screen will refresh). DirectDraw, though deprecated, is still supported as of now and is decently suited for 2d games and animations in general. I recommend you take the time to learn how to use the DirectDraw API and use that to do your drawing if this is not too impractical. I posted a link to a good tutorial in another thread. The problem with converting to DirectDraw lies only in the issue of porting from a Form based game to a DirectDraw based game, something that, from my experience, requires a complete redesign and recoding from scratch. But don't break a sweat yet, this might be able to help you: Another problem, more significant, is that by default picture boxes and forms in general are not double buffered. There are many online tutorials on implementing double-buffering for Windows Forms in C#.

1 Reply

Know the answer? Post it — somebody with the same question will find it here.

Mykonine22y ago
The problem is not in your programming, but in the nature of the System.Drawing library. Forms use GDI+, a drawing API which is naturally slow and not designed for use in games. The cause of the slowness is due to GDI+'s noticeable and inherent sluggishness in the complexity of the routines used by the library as well as the high level of abstraction, an issue that cannot be avoided when it comes to working with graphics in forms. You can remedy this somewhat by using the Graphics.DrawImageUnscaled method to draw an Image directly onto the Form's client area. As animated GIFs contain frame rates varying from 0 to some neglegibly large number of milliseconds, GDI+ is simply not suited to do the job for any frame shown for less than 50 milliseconds. ThreadPools are just alternatives to normal threading, which will not fix any problems when the drawing routines themselves are too slow. The best solution involves not using the default drawing routines, but rather an API that is better suited towards animation: Managed DirectX operates at a much lower level of abstraction and makes use of certain optimizations like drawing routines written in assembly, and thus performs drawing routines at much higher speeds (in the case of animated GIFs, as quickly as your screen will refresh). DirectDraw, though deprecated, is still supported as of now and is decently suited for 2d games and animations in general. I recommend you take the time to learn how to use the DirectDraw API and use that to do your drawing if this is not too impractical. I posted a link to a good tutorial in another thread. The problem with converting to DirectDraw lies only in the issue of porting from a Form based game to a DirectDraw based game, something that, from my experience, requires a complete redesign and recoding from scratch. But don't break a sweat yet, this might be able to help you: Another problem, more significant, is that by default picture boxes and forms in general are not double buffered. There are many online tutorials on implementing double-buffering for Windows Forms in C#.
0