Trying to make my windows form lighter

Question

I have a form that contains so many controls and does lots and lots of interactive actions. This is causing my form to have some delays during usage. One of these controls is a plotting tool that plots lots of data recieved from my server. I thought of moving the ploting tool to another form trying to make my form lighter, reducing the delay problem. I have been told by a friend that this won't help much since it is the same thread handling both of the forms, is that true ?

try looking here http://stackoverflow.com/questions/1566791/run-multiple-ui-threads — Diego D, Jul 28 '12 at 10:55
does that mean if I open my second form using Application.Run, it would be using a new thread ?! — Emo, Jul 28 '12 at 11:14
I wrote just a comment and not an answer because I was not sure what he actually meant. It was quite confused and since I couldn't try such a code I didn't feel confident enough to state a clear explanation. I may just suggest you to try and see what happen maybe using a simpler scenario to prove the concept. The answer seemed accepted in a confident way as you can see on the comment. By the way I don't understand why he created 2 joined threads and then just called Application.Run just for one Form. Is it supposed to work when you call Application.Run on the second? Try — Diego D, Jul 28 '12 at 11:18

score 2 · Accepted Answer · answered Jul 28 '12 at 12:04

What your friend says is true but it is unlikely to apply here. A form appears sluggish when it has a lot of controls. When it needs to redraw itself then you'll start noticing the time taken by every control to paint itself. Typically that happens when the form has around 50 controls, but greatly depends on the type of control. Buttons are very expensive, labels are not, for example. Your plot is likely to be expensive so anything that's drawn after it (higher in the Z-order) will be delayed. Try right-clicking the control and click "Bring to Front" so it is drawn last.

Whatever you do, never just make drastic changes like you are contemplating without knowing that you'll improve your program. Which requires measuring first. You'll need a profiler to know where the cpu cycles are being consumed. Profiling painting code is not so easy, given that it doesn't execute very often. That can be fixed, modify your form constructor so it looks like this:

    public Form1() {
        InitializeComponent();
        Application.Idle += new EventHandler((s, ea) => this.Invalidate());
    }

Your form now burns 100% core, repainting itself over and over again. But is otherwise still completely functional. Just what you need to effectively profile the painting code.

score 0 · Answer 2 · answered Jul 28 '12 at 11:04

0

If you create the form (plotting tool container) on application start, then your start speed well be down...

Then you have 2 way:

1) Move plotting tool container to a new form, but create it when it is require (after application started)

2) Move plotting tool to a new thread. in this case you can move it in an another form and create it by a new thread. so if you use this way your start speed will be go up

answered Jul 28 '12 at 11:04

Ramin Bateni

16,499
9
69
98

It is not the start time that has delay, delay occurs in the reaction of the form cause of some user actions. – Emo Jul 28 '12 at 11:10

score 0 · Answer 3 · edited May 23 '17 at 11:55

0

Starting from the answer given here

I've just tried the code and slightly modified it to make it clearer:

static void Main()
{
    Thread t1 = new Thread(Main1);
    Thread t2 = new Thread(Main2);

    t1.Start();
    t2.Start();

    t1.Join();
    t2.Join();
}

static void Main1()
{
    Application.EnableVisualStyles();
    Application.SetCompatibleTextRenderingDefault(false);
    Application.Run(new Form1());
}

static void Main2()
{
    Application.EnableVisualStyles();
    Application.SetCompatibleTextRenderingDefault(false);
    Application.Run(new Form2());
}

I can say it works because I tried using a Thread.Sleep() in one of them and the second form gui didn't lock.

edited May 23 '17 at 11:55

Community

1
1

answered Jul 28 '12 at 11:29

Diego D

6,156
2
17
30

hmmmm ... i tried to do the same without using Application.Run,form.showdialog(), and got the same result of you !! does it mean that each form has its own thread !?! I am back to my frist point that raised up this question – Emo Jul 28 '12 at 11:53
actually the original answer talks about "message pump". Yes we have a thread per Form and each one will process the messages coming from the OS and keep the UI alive independently. Usually when you have an heavy routine running on the UI thread the UI gets locked because it doesn't return immediately and doesn't give the chance to the Form to process its messages. That's why that kind of stuff should be run on different threads (there are several options to make this). Anyway since you talked about a Form Control this seemed the most straightforward solution to implement. – Diego D Jul 28 '12 at 12:03
Application.Run() doesn't return until the Form is closed. So you may not run two different forms at the same time without using two different threads. Of course you can if you instantiate the second from the first and then you show it, but the message pumps will be chained on the same thread causing locking when one of them is stuck on a routine. – Diego D Jul 28 '12 at 12:07

Trying to make my windows form lighter

3 Answers3