I'm in-disposed

[Ommina]

So, speaking of

Code:

uiButtonStrip.Dispose();
uiButtonStrip = new UiButtonStrip("ButtonList", yourButtonList, this, new HashTable(), skinHelper);

Are there any other additional steps developers should be watching for to ensure that everything gets disposed as appropriate?

In my case, I do a lot of switching content within a listview around as the user wanders up and down the tree. Noting that the ListObject doesn't have a .Dispose(), I've simply been creating a new List<> and stuffing it in via SetListObjects(). Is this sufficient? Should I be disposing the owner object first and creating a new one (as with the ButtonStrip, above)? If I have 1000 cover arts loaded, I'm anxious not to leak them!

Any thoughts, both for the list view specifically, and managing bitmaps in general ?

Edit: I find it also gets annoyed with me if I manually dispose of popups once they return. Does this mean the current popup is disposed by npvr when activatePopup() is given a null?

[InVermont]

I was always under the impression that if my code created something, my code needed to destroy it. So when switching the contents of the uiList, I do something like

private void cleanupOldUIList()
{
List<UiList.ListObject> lst = uiList.GetListObjects();
if (lst != null) {
for (int i = 0; i < lst.Count; i++) {
Bitmap b = (Bitmap)lst[i]["@previewImage"]; //the bitmap I loaded earlier
if (b != null) b.Dispose();
lst[i].properties.Clear(); // there are a couple of strings in this hash also.
}
}
uiList.Dispose();
uiList.SetListObjects(new List<UiList.ListObject>(), 0);
}

It doesn't crash, but that doesn't mean it is correct or needed....
Curious to see what Sub says.

[sub]

There is a couple of different types of resources to be aware of.

1) Large .NET objects like Bitmap etc. These consume a lot of memory. They're typically garbage collected automatically when no longer referenced by anything, but because they're large its nice to Dispose() of them if you know they're no longer in use.

2) Unmanaged objects, like the direct3d texture memory used by UIElement objects. These are not garbage collected, and need to be manually Dispose()'d of to force the texture memory to be released to the videocard. If you're manually creating UIElement objects, then call Dispose() on them if you no longer need them. If you're using higher level controls like UIStatic etc, calling Dispose() on these controls will automatically call Dispose() on the UIElement object's it owns.

[mvallevand]

Sub, can we assume those Slim3d windbg messages at exit are the unmanaged resources being freed? I seem to introduce lots of them and I guess I need to Dispose more often.

Martin

[Ommina]

Sub, can we assume those Slim3d windbg messages at exit are the unmanaged resources being freed? I seem to introduce lots of them and I guess I need to Dispose more often.

You mean the list of

Object of type SlimDX.Direct3D9.VertexBuffer was not disposed. Stack trace of object creation:
Object of type SlimDX.Direct3D9.Texture was not disposed. Stack trace of object creation:

that is spammed out when npvr closes? I was wondering about those too, now that you mention it.

Large .NET objects like Bitmap etc. These consume a lot of memory. They're typically garbage collected automatically when no longer referenced by anything, but because they're large its nice to Dispose() of them if you know they're no longer in use.

I prefer to explicitly dispose rather than rely on finalize. Does that mean I should be doing much like InVermont is doing with his lists? I'm careful to call dispose when it is there, but I admit I've never gone back and plucked the bitmaps back out.

[sub]

Sub, can we assume those Slim3d windbg messages at exit are the unmanaged resources being freed?

Yes. There is quite a few things NextPVR doesnt explicitly release, and instead just leaves Slim3D to clean them up at exit. ie, id doesnt bother disposing stuff at app exit. It does try to make sure it doesnt leak though, so popups or any recreated controls are disposed during normal operation.

[sub]

I prefer to explicitly dispose rather than rely on finalize. Does that mean I should be doing much like InVermont is doing with his lists?

Its complicated to give you any definitive instructions on this. It really depends how you're managing the life cycle of your images. I dont do anything explicitly like InVermont's example, but I'll often use the ImageCache class, which caches a couple of hundred images, and will auto dispose any older images that get pushed out of the cache.

It might help you to know that NPVR will only ever Dispose image objects that it creates. Image objects you create are managed by you (whether you rely on garbage collection or explicitly Dispose).

[Ommina]

It might help you to know that NPVR will only ever Dispose image objects that it creates. Image objects you create are managed by you (whether you rely on garbage collection or explicitly Dispose).

It does help, significantly in fact. Indeed, up until about five minutes from now I have been creating creating new image objects when returning them from the cache, since I didn't want them disposed out from beneath my feat (and leaving me with an oh-so-helpful 'invalid parameter' exception).

Armed with this new knowledge, I'll change my strategy somewhat.

Related -- has anybody found a caching approach that provides a good balance between memory consumption and speed? Do you resize first, then cache the resized version, or store one copy and resize as needed? Or an even simpler when the getImage callback comes knocking, just answer with a "here's your image, if you don't like the size, YOU deal with it"?

[mvallevand]

I don't know if it is important or not but I find that most of those Slim3D message that my plugin makes are in .GetRenderList() This function does seem to reduce the number of messages at the end

Code:

void killRenderList(List<UiElement> element)
        {            
            if (element != null)
            {
                for (int i = 0; i < element.Count; i++)
                {
                    if (element[i].GetType().ToString() == "NUtility.UiElement")
                    {
                        UiElement ie = (UiElement)element[ie];
                        Bitmap b = (Bitmap)ie.image;
                        if (b != null)
                        {
                            b.Dispose();
                        }
                        if (ie.internals != null)
                        {
//                            Debug.WriteLine(ie.internals.GetType());
                        }
                        ie.Dispose();                    
                    }
                    else
                    {
//                        Debug.WriteLine(element[i].ToString());
                    }
                }
            }
            element.Clear();
            
        }

Martin

[sub]

You probably wouldnt need to do that. Calling uiList.Dispose() and .Dispose() on any other UiXXXX controls, should take care of it.

ie, you're probably not creating these lower level UiElement objects yourself, but instead having them returned from the uiList's cache etc.