Remove reference counting from bitmaps

[nickhepp]

Instead of referencing counting bitmaps b/c their memory is a precious
commodity lets try to find a suitable replacement and discard bitmaps
as we dont need them. The reference counting can be a blood mess,
especially across multiple threads, plus I did not care for the bitmap
pool at all and how once you started using it, you were always using
it, bleh.

This will be a considerable overhaul but probably better in the long
run b/c it was quite annoying to run out of memory instead of using
page files like other resources. Possibly this could lead to much
bigger images that could be produced. Turns out .NET is really
limiting on how large it likes the images to be.

[nickhepp]

Get rid of BitmapPool

Bitmaps are now throw away objects only to be used long term for controls. Only controls and other things that absolutely have to will hang on to bitmap references. Many times when we are looking at an image it is only to get image stats. Maybe we can find a better way around that. (ImageMagick.NET)

Create final mosaic out of raw 24bit bitmap byte stream assembled from scratch (or a class that is a really good helper). Basically use GDI+ for little images.

Controls should have some sort of scaling applied to them so they dont need huge Bitmaps to show off. This will be good in long run b/c the apps will be more responsive.

When a control is disposed it should destroy its bitmaps. How can we track all the controls and bitmaps looking for memory leaks? Maybe put an interface on all these controls and have them added at creation time and disposed of when they dispose of each other. Control is added through its own cstor, removed by it raising an event in its own dispose function.

//Possibly a replacement for GDI+
http://magick.codeplex.com/releases/view/115159

[nickhepp]

Just a quick overview, the method proposed by this blog post injects a callback method into the Win32 API to track when GDI resources are created and destroyed, along with tracking the call stack, so you can track resource usage along with identifying where resources are allocated or possibly leaked. Please note that I am equating leaks to excessive resource usage which I believe leads to the same problem - scarcity of resources. Im not trying to say our code is leaky.

To read more:
http://geekswithblogs.net/akraus1/archive/2014/01/03/155056.aspx

I have also seen two applications come up for debugging GDI resource issues: VMMap and GDIView. While the blog post seems quite involved, these two apps seem like they could shed some light possibly w/o too much work.