# [.net] When to Dispose() in MDX

This topic is 4623 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

public void FillRect(int x, int y,int x2,int y2,int r,int g,int b, int a)
{
Surface rt=device.GetRenderTarget(0);
device.ColorFill(rt,Rectangle.FromLTRB(x,y,x2,y2),Color.FromArgb(a,r,g,b));
rt.Dispose();//<--needed?
}

In the docs of .net, m\$ said that Finalize should call Dispose when Dispose is not called, which is called when the object is collected. But if I don't call rt.Dispose(), my test program will keep eating up the ram(FillRect is called every frame). So, when should I call Dispose() on a object? I thought .net should manage all these stuff, or it's a bug in mdx? thanks

##### Share on other sites
While I may be oversimplfying it, I think calling Dispose() should be done when you know you're not going to be using an object anymore. Furthermore, I've read that if the IDispose interface is implemented you SHOULD call Dispose when you can. Especially in the case of using a render target. Typically you'd wrap that up in a using {} statement (which automatically calls Dispose if I recall). I really can't recall much about why all of this is necessary, but I'm pretty sure that if you leave the object hanging around for the GC to collect it'll be much slower. Further, I think I read somewhere that disposing of a render target specifically calls the Release() functionality of the internal COM pointer, which means if you don't call Dispose you'll probably end up with nasty memory leaks (which will appear in your debug output as memfini errors if I recall).

I know this isn't probably the most accurate representation of why things work the way they do, so I would suggest looking around for more information about Dispose and information related to the using {} statement and render targets.

Hope that helps a little.

##### Share on other sites
You dont need to call Dispose() ever, as finalizer will take care of it... Of course, you can call it if you want to free some memory sooner...

For start try disabling MDX event handling before creating surface:
Device.IsUsingEventHandlers = false;

Then you could also try forcing GC... If it doesnt help, it could be a bug in mdx...

##### Share on other sites
Well if you dont call Dispose on an object that implements it, you will end up with object living for at least 2 collections. This is quite bad, since some objects may be move to generation 2 where its hard and time consuming to remove them. So on every object that implements Dispose its good practice to call it yourself. Or use the using statement to do it automatically.

##### Share on other sites
Quote:
 Original post by BulmaYou dont need to call Dispose() ever, as finalizer will take care of it... Of course, you can call it if you want to free some memory sooner...For start try disabling MDX event handling before creating surface:Device.IsUsingEventHandlers = false;Then you could also try forcing GC... If it doesnt help, it could be a bug in mdx...

I tried Device.IsUsingEventHandlers=false; before creating the device, and it works, but what does it have to do with memory management in MDX?
It seems to be a design flaw to me...

Btw, are we going to have a better optimizing JITer in .net 2.0?

##### Share on other sites
Well, MDX is setting event handlers (for device.OnReset, etc), so if device goes into reset, you dont lose your surface, texture, mesh, whatever... You probably read in documentation that when you create objects in "Default" pool (video memory), you have to create them again after reset.. Well, with this feature, you dont have to do it manually...

And because of this events attached to Device, gc cant collect those objects...
Its a feature, not a bug... [wink]