How to debug slow screen repaint in Vb.net winforms

Question

0.00/5 (No votes)

See more:

I need some help trying to debug a slow repaint issue with one of my Vb. Net WinForms programs. When the program is first started the screens repaint just fine. After the program has ran for a few hours, you can start to notice the screens taking longer to repaint. After the program has run for over 24 hours, the screen repaint takes about 10 seconds. It eventually gets to a point where it gets so slow that you have to shut the program down and restart it. After restarting the program, the program screens repaint fast again but then start to slow down the longer the program runs. I’ve read that slow repaint can occur on Forms that have many controls. The most complex form I have has about 100 controls and does not include a lot of control nesting.

I have this same program running on multiple computers which use 2 different operating systems. Most of the computers are running Windows 2000 SP4 but we also have a couple running Windows XP. The slow repaint issue only happens on the computers running Windows 2000.

I first thought I had a memory leak with some of my GDI objects so I ran GDI view and found a few small issues that I have since corrected. Now when the program runs, there is rarely over 100 GDI objects open at any time and it doesn’t seem like its creeping up anymore.

When I was doing some my testing, I noticed what I first thought was a handle leak. I left the task manager open and I noticed that the handles went up to about 1500 but then reset back down to 500. I did some investigating and discovered that the handles increased anytime the background thread fired an event that updated the GUI thread via invoke. The background thread in my program constantly captures the same data from an external process every few seconds. I have the background thread running in a Do while loop. Is it normal for the handles to increase like that? This is my first project using a continuously operating background thread so I’m a little green at doing this. Here is my code for updating the GUI thread:

SQL

Public Sub SetText(ByVal ctrl As Control, ByVal text As String)

       'This sub updates the text to the required control
       If ctrl.InvokeRequired Then
           ctrl.Invoke(New SetTextDelegate(AddressOf SetText), ctrl, text)

       Else
           ctrl.Text = text
       End If

   End Sub

When I tracked the number of handles on the Windows 2000 system, the handles started out at over 7000 right when I started the program but then stayed very steady. Does anyone know why there is such a big difference in the number of handles reported by task manager on the 2 different systems? Are they reporting the same thing?

Does anyone have any other ideas on what is causing the screen repaint to slow down? Since I’m not having the issue on the XP systems, could it be something as simple as adding more memory to the Windows 2000 systems?

Posted 21-Apr-15 2:51am

theskiguy

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2015-04-21T03:43:00

The leak in GDI objects is not the only possible memory leak. And the leak in any other unmanaged object is not the only possible memory leak. It could also be a managed memory leak, but that could be a different kind of leak, leak "by design" or by mistakes in the general code design.

Please see my past answers on the topic with some code design advice:
Memory leak in WPF DataBinding[^],
Memory management in MDI forms[^],
Best way to get rid of a public static List Causing an Out of Memory[^],
deferring varirable inside the loop can cuase memory leak?[^],
Garbage collectotion takes care of all the memory management[^].

Now, some mode advice:

First, don't trust Task Manager, just don't. If you cannot resolve your problem purely analytically, try to find and use some real memory debugger: http://en.wikipedia.org/wiki/Memory_debugger[^].
I did not use any of them (so far so good :-)), so I cannot recommend anything in particular, you may need to make your choice by yourself, get some experience.

Finally, you reported having many GDI objects and handles at the same time. This could be a sign of bad application design. So, I would advise to review your design.

—SA