Skip to main content
GameDev.net gamedev.net
🔒 Locked

[.net] [VB.NET] DirectX Control and memory leaks

Started by MePHyst0 Jan 21, 2006 at 9:06 AM 12 replies 4.5k views
Original Post
MePHyst0
MePHyst0
Hi, I started working on a small DirectX UserControl with Vb.NET. So I made a simple skeleton of the control, then I tested it with a simple render loop cleaning the UserControl area to Blue. That went fine, however I've noticed that the process keeps allocating more and more memory(aproximately 30 kB/s). Have anybody any idea what can cause these memory leaks? Thanks in advance P.S.: I've just tried the CreateDevice tutorial from October SDK and it's leaking the memory too. Can the bug be in my workstation?
DrGUI
DrGUI
Hi

I had a memory leak problem before, put your debug runtime on max validation and full verbosity. Some kind soul then told me to search for DebugView to see the debug output, very neat tool.

Here is my cited thread.

Argh further maths exam (AS D1 module) at 1...wish me luck! I _can_ get 100% but it takes 2hrs rather than 1hr30 :( I'm slow and stupid :(

Bonne chance
MePHyst0
MePHyst0
Hi,

Thanks for your reply. I've alredy checked the debug output(everything set to maximum) with no success. It says that there's nothing wrong.

I'm totally lost, I've tweaked everything and the leaks were always there. Please, If anyone could give me any hint/advice, I would appreciate it a lot. Thanks a lot.
Washu
Washu
How are you doing your render loop? A code sample would be useful. Just telling us that "memory keeps getting allocated" isn't particularily helpful since we have no idea what your code is doing.
In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.
alexmoura
alexmoura
Agreeing with Washu (duh! ;)) - it might not even mean you have a memory leak when you're dealing with garbage collectors - it probably does mean you should reconsider the alocations you're doing, since you probably will end up with the garbage collector kicking in at innoportune times and causing random slowdowns.

Basically, remember that the Vb.net garbage collector works different from the vb6 one.
DrGUI
DrGUI
If debug output shows nothing (does not spew out lots of stack traces for unfreed memory), probably saying 'Mem fini!' at the end, then it's probably not DirectX's fault.

Like others said, it's probably the normal operation of the garbage collector.
I believe the CreateDevice tutorial uses Application.DoEvents...not a good thing:
Quote:
Rick's blog
The first loop I used was the old standby loop: 

while (Created){   Frame();   Application.DoEvents();}


Sadly, this loop is mortifyingly bad about allocations. To give you an example, if you do nothing else in a frame, this kind of loop can generate over 50MB of garbage in 100000 frames. Under CLR profiler, you’ll see a shark tooth pattern of allocation and collection emerge in the timeline. Lots of collections == bad long-term performance.


Check out Rick's and Tom's blogs. (and this is Tom's post on the render loop)

Hope that helps
MePHyst0
MePHyst0
Thanks a lot guys. The link to those blogs were quite helpful, the memory allocation decresed dramatically, however there's still some ignoreable overhead.
Anyways, I'm having some problems with those game loops. I've tried to implement this game loop, however it's seems that my form is not recieving any message. Here's my implementation:

Private Declare Function PeekMessage Lib "user32" Alias "PeekMessageA" (ByVal lpMsg As Message, ByVal hwnd As Long, ByVal wMsgFilterMin As Long, ByVal wMsgFilterMax As Long, ByVal wRemoveMsg As Long) As Long    Private Sub OnApplicationIdle(ByVal sender As System.Object, ByVal e As System.EventArgs)        Do While AppStillIdle()            UserControl11.Render()        Loop    End Sub    Private Function AppStillIdle() As Boolean        Dim msg As Message        Return (Not PeekMessage(msg, 0, 0, 0, 0))    End Function    Private Sub StartMainLoop()        AddHandler System.Windows.Forms.Application.Idle, AddressOf OnApplicationIdle    End Sub


Do you see any mistakes in my code?


[Edited by - MePHyst0 on January 25, 2006 3:07:58 PM]
MePHyst0
MePHyst0
I apologize for the bump, I would appreciate any help :)
gwihlidal
gwihlidal
For starters, and it may be from just pasting a fragment of your code, where are you calling StartMainLoop() to attach to the Idle event? Just want to get that out of the way first.

Also, are you calling Application.Run()? I'm assuming you are, but there are alternative ways to doing this that you may be trying which could be causing issues.

~Graham
MePHyst0
MePHyst0
Hi,
Thanks for your reply. Here's the missing code:

    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load        StartMainLoop()    End Sub    Shared Sub Main()        Application.Run(New Form1)    End Sub


Sub Main is the entry point of my application.
MePHyst0
MePHyst0
Yes, the Idle event is firing, the problem was in the While cycle and AppStillIdle function. I changed it to something like this:

       Do            UserControl11.Render()        Loop While AppStillIdle()    Private Function AppStillIdle() As Boolean        Dim msg As Message, res As Long        res = PeekMessage(msg, Me.Handle.ToInt32, 0, 0, 0)        If res <> 0 Then 'non-zero            Return False        Else            Return True        End If    End Function


As you can see VB handles differently the long -> boolean conversion than C#. Anyways, the memory allocation problems are still there, but the allocated memory is significantly smaller.

It's quite strange that when I minimize my form the extra allocated memory is gone...but in normal state the allocation continues
gwihlidal
gwihlidal
I kind of figured it was the return value on SendMessage. Glad you worked it out.

Tom Miller's render loop isn't perfect, but it's a lot better than spamming Application.DoEvents() (which has a significant leak, though most applications don't need to purge the message queue, though games are where this nasty leak shows up most).

What Microsoft needs to do is come out with a Direct3D context control that provides optimize rendering performance (but can also switch to fullscreen with just a toggle method. Such a component would be well needed.

~Graham
Kal_Torak
Kal_Torak
I'm not sure if you people have seen PIX, but it sounds like it would help you find performance problems quite well.

http://channel9.msdn.com/showpost.aspx?postid=109396

If you gave a helpful reply, I rated you up.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.