RasterImage.Dispose()

I notice that when I load many large images into RasterImage objects, then remove my references to the RasterImage objects (for instance, loading lots of large images into MedicalViewerCell's, then clearing the cells in the viewer), it takes quite a while before the memory consumed by the RasterImage objects is collected. The amout of time it takes for the .Net Framework to collect my objects doesn't change depending on image size either. Does the RasterImage class inform the .Net garbage collector when it allocates or deallocates large chunks of unmanaged memory (for instance, through methods such as GC.AddMemoryPressure() and GC.RemoveMemoryPressure() ) or am I responsible for doing this?

We do not inform the framework to do a garbage collection. Like
any managed object in .NET, when you dispose of our objects, they are not
actually freed from memory at that point, only marked for deletion. The
framework at certain points will perform a garbage collection which frees any objects marked for deletion.

 

To force a garbage collection, you could call GC.Collect and GC.WaitForPendingFinalizers.

Hi Yasir,

I think you misunderstood my question, and I think I could have phrased it better in any event. I understand how .Net garbage collection works, what I meant is, the .Net garbage collector can only manage the memory associated with managed objects, however because the RasterImage class manipulates unmanaged memory, unless you tell the garbage collector that the managed RasterImage object is really just a wrapper around a big chunk of unmanaged memory the .Net garbage collector wont ever be aware of the implications of having a whole lot of undisposed RasterImage objects sitting around.

This means that if you have a whole lot of unreferenced RasterImage objects sitting around (because you just cleared the cells in the viewer for instance) and hardly any system memory available (because the unmanaged bitmap each RasterImage object contains is using it all), the garbage collector won't have any idea that a simple gargage collection interation targeted at these objects would free up a bunch of that memory, all it knows is that memory *on the system* is low, not that it's inadvertently the one who holds the power to free that memory. There are ways of letting the garbage collector know that a managed object, that to it seems to be a low memory object, is really just a wrapper, or gatekeeper, for a large amount of unmanaged memory (for instance, the GC.AddMemoryPressure() method), and what I wanted to know is whether or not LeadTools have implimented such method calls (because if not, in my application I really should).

GC.Collect and GC.WaitForPendingFinalizers wont always help if the garbage collector doesn't know that there's a very urgent need to free up these specific resources, it'll go off and dispose objects holding what it believes to be much larger chunks of memory, which in reality are much smaller.

We do not call this method internally. Instead, we free all unmanaged memory when the RasterImage is disposed. When you no longer require the RasterImage, you should call it's Dispose method and internally, all unmanaged memory will be freed.