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!
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.
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?
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.
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.
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.
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?
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:
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.
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.
I’ll go out on a limb and say it’s comparable to C++, iff you understand the limitations and work around them carefully. Once you understand the limitations, then you’ll have a frame of reference for comparison; otherwise it’s kinda like comparing apples to oranges.
Wouldn’t suggest doing a AAA shooter with it. But then again you might be surprised by what you can do with it.
Above all, avoid p/invoke like the black mamba (mechanism for calling into native dlls, like Java’s JNI). That means reducing the number of calls into the API to the absolute minimum. And as Stephen suggested, avoid creating mounds of garbage on the heap (which’ll invoke the garbage collector willy-nilly) and you should be fine for most things.
Incidentally, and quite ironically, it’s actually easier to interop in C# with GL than it is with DX!
Best thing about C# and .NET is that it’s a squeaky clean coding sandbox, a real pleasure to use in VS05.
Worst thing is realizing that it’s not C++, right when you really need it to be.
It’s great, but be prepared to lose a few hairs in porting C/C++ code. Having tinkered quite a bit with .NET I find I really miss native C++.
Just echoed a lot of what Stephen said but I was on a roll and got my sleep-deprivation-induced muse on
Edit: I need one of those context sensitive spell checkers…
It’s funny how leaving a problem for a while allows the solution to present itself (psychologically I believe it’s a process called Incubation). Well, I returned to the original problem and finally managed to get my unmanaged C++ OpenGL panel working in a C# .NET form under Vista! The problem was nothing to do with OpenGL, SwapBuffers or glFinish after, it was the panel’s parameters.
Following Zengar’s advice I revisited the Tao C# example control. I extracted elements I believed to be relevant, converted these to C++ .NET and found all that was needed was to override the CreateParams property…
property System::Windows::Forms::CreateParams^ CreateParams {
virtual System::Windows::Forms::CreateParams^ get () override {
In fact, the only flag that was needed to make it work in Vista was CS_OWNDC. In previous attempts I think I was lazily setting these in the constructor! Better catch up on .NET then!
I am one of the developers of Intoi (http://www.intoi.net/), a digital whiteboard solution using the TAO Framework. I can definitely tell you that we have never had any performance issues with TAO. I can definitely recommend TAO Framework as the “libarary of choice”!
If you have any questions, do not hestitate to contact us via email.
