Improve WPF Garbage Collection Performance

[ftlPhysicsGuy]

If you're using SharpGL in a WPF application, and you're using RenderContextType.FBO, then when the OpenGLControl responds to its DispatchTimer's Tick event (see the timer_Tick method in OpenGLControl.xaml.cs under the OpenGL.WPF folder) it will call the static HBitmapToBitmapSource(IntPtr) method (see BitmapConversion.cs). To prevent possible memory problems when too much is going and and garbage collection isn't fast enough, the HBitmapToBitmapSource method includes a call to GC.Collect() in a finally block that occurs with every call.

I have found this to cause too much of a slow-down with fast changing scenes, and to speed things up, I've made the following changes: I added a "static int gcCount = 0;" and a "static readonly int MaxCyclesBeforeGC = 50;" to the BitmapConversion class. Then, in the HBitmapToBitmapSource method's finally block have the following instead of the GC.Collect() call:

 gcCount++;
 if (gcCount > MaxCyclesBeforeGC)
 {
     gcCount = 0;
     GC.Collect();
 }

You can play around with the value for MaxCyclesBeforeGC, but NOT calling GC.Collect() with every cycle makes for a much smoother result and performing the garbage collection every so often seems to keep any memory problems in check.

Just a friendly suggestion.

[dwmkerr]

@ftlPhysicsGuy thanks for this information, I'll include changes based on this in the next release :)

[ThVoss]

Hi,

I've found the similar issue and suggested a slightly different solution on codeplex: https://sharpgl.codeplex.com/discussions/561740

The advantage of using a GC Thread which blocks until GC is done is that you do not call GC multiple times until it finished. Additionally, by creating a thread you do the GC async. This is beneficial as a call to the GC might block anyway which will result in frame rate drops.

Cheers Thomas