OpenGL in .NET / Vista

[fuggbar]

A while ago I developed a simple demo which rendered OpenGL on a .NET form. A subclass of the Windows Forms Panel class was developed in C++ .NET to render the scene and handle interaction from the user. This was added to a simple C# form and ran fine under XP.

On Vista, I've had problems getting the Panel to render correctly. The code remains unchanged. I've tracked the problem down to SwapBuffers. When I create a single buffered context and end my render code with glFinish(), it seems to run fine. When I use a double-buffered context and end the render code with SwapBuffers() the OpenGL content within the panel is not always rendered. On resize and mouse input the view will re-render at seemingly random intervals, sometimes it will not be displayed at all.

I've also noticed issues in using OpenGL with Win32 on Vista - on XP it's easy enough to have multiple viewports in multiple windows / dialogs using a single context - but this seems to fall apart in Vista.

Could anyone let me know if I've missed an obvious step in moving OpenGL code from XP to Vista. I guess it's easy to blame driver maturity, but I'd like to eliminate my code first!

Thanks.

FB.

[Zengar]

Make sure you don't render to the front buffer (due to desktop composition). Also, make sure you have latest drivers installed. It is also possible that your custom created control is not written correctly. The Tao library has en example for such a control, maybe you should have a look on it.

[Lindley]

Someone was having trouble with single-buffering causing a huge memory leak in Vista here , while double-buffering did not. I wonder if this could be related?

[fuggbar]

Thanks for the suggestions -

I've just downloaded Tao for .NET 2.0 and I'll check out the control you mention Zengar to see if there are any significant differences in the implementation.

Lindley - I've not checked for leaks in single buffered mode (which seems to work okay) - but I'll certainly check this out - thanks for the link.

FB.

[fuggbar]

I checked out the Tao control - the example I've worked from is derived from UserControl rather than Windows::Forms::Panel but the OpenGL code remains pretty much the same.

I find I can circumvent the problem if I turn off desktop composition for the built C# application - the Color Scheme reverts to Vista Basic and Aero effects vanish, but the OpenGL works fine - not ideal but at least it works!

I've also found this solves my multi-window/viewport Win32 problems as well.

[Zengar]

Then it would be a problem with your rendering code somewhere - it seems to be incompatible to vista compositor. You can still use the new Vista API to switch the composition on. I think the function was called dwmEnableComposition() or similar.

[Hampel]

Are there any experiences about real time or interactive performance with C#/.NET and OpenGL? For example, the TAO examples are only basic OpenGL ones; how does it perform with larger dataset to render or with C#/.NET based scene graphs?

[Stephen A]

I have done some performance tests on Tao.OpenGl (being its current maintainer), but not on any large scale.

The following results were taken with the OpenTK library using .Net 2.0 (x64 mode), on a 3.2GHz Intel Core 2 Duo. They are valid for the latest Tao.OpenGl beta (2.1.0.11), while the released Tao.OpenGl dll (2.1.0.4) will exhibit lower performance in the "OpenGL core functions (array)" case - equal to the (void*) case:

GL.LoadAll(): 910 OpenGL extensions loaded in 238 milliseconds.
Number of calls: 1000000
Timing empty loop: 0,3136 ns
Timing inline .Net functions: 1,8952 ns
Timing virtual .Net functions: 2,6939 ns
Timing OpenTK.OpenGL core functions: 28,254 ns
Timing OpenTK.OpenGL core functions (array): 28,8711 ns
Timing OpenTK.OpenGL core functions (void*): 173,228 ns
Timing OpenTK.OpenGL extension functions: 27,7283 ns
Timing direct DllImport: 24,7574 ns
Timing direct DllImport (array): 23,4221 ns
Timing direct DllImport (void*): 2569,1866 ns

As you can see, there is an inherent performance deficit associated with unmanaged function calls from managed code. I am investigating methods to lower this cost in the future (probably by generating the necessary IL directly, instead of going through the compiler), but it will never be as fast as a direct function call. However this may not matter much in a large scale application, where memory management, math calculations and threading tend to play a much bigger role.

Provided you are careful with the Garbage Collector (use object pools and avoid frame-to-frame allocations) and parallelize tasks correctly, managed code will perform very close to unmanaged code. The *biggest* problem are math calculations, which tend to be inefficient in jitted code. You can partially combat this by offloading calculations to the GPU (skinning for example), and/or calling into native, optimized math libraries.

[Hampel]

Thanks for your detailed explanations... So, if one tries to minimize OpenGL calls these performance penalties are not that bad, I think.

But I am really interested in experiences with real world applications not just benchmarks and small samples... :-)

[Stephen A]

There is at least one large-scale project that uses the Tao Framework: http://www.intoi.net/ I'm sure these guys could answer a few performance related questions if you ask politely ;-)

I have also heard that at least one Nvidia product uses the Tao Framework, but I do not know which one - or which version it uses.