Windows Forms applications are typically less snappy than Win32 applications. As I understand it, part of the reason is that the drawing library uses GDI+, which does not benefit from the same acceleration as GDI in typical video drivers. There must be other factors too.

A while back someone coded an application to test the performance of various languages/compilers. C# and VB.NET came out very badly, and I took a look at the code. The application simulated various elements by drawing the movement of atoms on the screen, and most of the time was spent in the drawing routines. On one example element, the original code was drawing about 350 frames per second on my system. I tweaked the code to use PInvoke to GDI for the performance-critical drawing routines, and the performance increased to around 4500 fames per second. It's an astonishing difference, and simultaneously shows how slow .NET drawing can be, and how you can keep your application in C# but dramatically speed performance with judicious use of a few PInvoke calls.

What .NET version were you using? This was a common issue on .NET beta versions. They've fixed it by .NET 1.1.
Do you know that the developer of Quake 2 ported it from C to managed C++ and it was even faster than the original version? For changed something for some reason though, that made it slower than the original version, but not much. You can download the code for free if you want to see it.

Hermann,

There is typically a huge difference between the speed of the .NET drawing methods and PInvoke to GDI even in .NET 1.1. I believe Quake 2 uses mostly OpenGL. Still an impressive demo though.

Tim

So how will this change in Longhorn/Avalon? As far as I understand, the managed interfaces will hook directly into DirectDraw. I could be wrong, of couse....