kellegous.com

A couple of weeks ago, I decide to port at least one of my little graphics projects over to C#. I was interested to see if I could take advantage of the “Microsoft finds ways to make its own products run faster than others while supposedly using the same API's” phenomenon to squeeze out a little higher frame rate. And, given that my latest experiments have little chance of making it to applet form, I thought I would make a quick stop into .NET on my way over to SDL and OpenGL. After all, writing in java…err C#, is far more fun that writing in C++. Yeah, I said it! The real problem with trying to do anything with .NET is the atrocious documentation. For all of the gripes that have been heaped on javadocs over the years, Sun has at least established the convention of inserting useful notes when something is designed to behave a little differently. For a good example, browse over to the java.util.Calendar class and try to figure out how to get an instance. It's noted in the description of the class. Similar documentation is often found in the remarks section of the .NET docs, but more likely not. One document that is noticeably absent (perhaps just impossible to find) is a thorough explanation of the event wiring [the .NET equivalent to Painting in AWT and Swing]. Since, I'm doing this trial and error, I thought I should at least share some of my tougher finds.

First, I was about to give up implementing a paint loop because the flicker was atrocious even with double buffering. It turns out that in addition to the Paint Delegate that is shortcutted through the OnPaint event for the Control class, there is also an OnPaintBackground event that will kindly refresh your background for you in the paint loop, producing epilepsy-inducing flicker. Yeah, you want to override that.

Second, I found that the java typical Thread.Sleep somewhere in the paint loop method of consuming necessary events does not get the job done in .NET. To make all the window events happy, I had to actually trigger my graphics loop with a System.Windows.Form.Timer (as opposed to a System.Threading.Timer or a System.Timers.Timer … I love senseless namespace confusion). Seems logical; the runtime apparently needs the Thread that I'm putting to sleep to finish up the Form events but, again, where is the document that explains this gunk. I assume it's available from Microsoft Press for at least $75.

[the code]