After I was done with the WinForms test harness update I noticed that the application was leaking memory like the Titanic after meeting an iceberg. I have managed to narrow the issue down to the OpenGL window – then I realized that the best course of action I could take here is to implement both a managed and a disposable wrapper for my library – mainly because I wanted to try out both possibilities. At first I thought that the leak was due to my wrapper, but it turned out it was more or less OK. Still, this overhaul was very useful, as I could get rid of a couple of hastily placed static variables that caused big problems for the wrapper’s lifetime management. (Static C++ variables kept their values even after I created a completely new object in C#, somehow I was expecting the library not to keep these globals around when the library is initialized from the outside from scratch, but I was wrong.)

First I created two separate wrapper projects, one expects the user to control the lifetime of the objects through the IDisposable interface (DisposableDeepTrainerWrapper), the other one relies on the garbage collector to clean up the wrapper and the C++ objects (ManagedDeepTrainerWrapper). Then I decided to make the WinForms test application use the disposable version of the wrapper, and the WPF application use the managed one.

The WinForms application have become quite a feature-full sample, so to reach the same level I had to get rid of almost all my existing WPF implementation, and start from scratch. The work is now done, I have managed to implement almost all features in the WPF version that I also had in the WinForms one.

There are still a couple of things to fix and final touches to add, but the main targets are achieved:

• The application is robust,
• It initializes the wrapper and the libarary properly (this is the first time I relied on a fully managed wrapper, so this was not 100% straightforward)
• It implements all the views the exact same way they are seen in the WinForms application.
• It is not leaking memory as far as the C++ library is concerned.

My only concern is the OpenGL wrapper I am using from NuGet called SharpGL, it seems to continuously grow the memory usage every time I create a new display list. This could be either a problem with the library or with the way I am using it, I will have to find this out and fix it somehow.