Reputation: 566
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 ?
Upvotes: 1
Views: 214
Reputation: 8152
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.
Upvotes: 0
Reputation: 941257
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.
Upvotes: 2
Reputation: 17395
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
Upvotes: 0