By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,827 Members | 2,195 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,827 IT Pros & Developers. It's quick & easy.

Higher CPU Utilization on Windows form resize

P: n/a
I have created a windows application in which the form needs to be
resized on the MouseMove event. The windows resize function takes a lot
of CPU cycles. And as the resize function is called on the MouseMove,
the form is resized around a 30-100 times in one second. This leads to
a high CPU utilization and all other application comes to a stand
still.

The form does not have any controls i.e. buttons, text boxes etc. It is
completely empty. Its opacity in around 10%.

Now is there any way by which we can reduce all the amount of CPU taken
by the form on resize??

Or can I reduce the form resize calls on MouseMove event. i.e. some way
by which all the mouse move event don't lead to form resize.

Please help me out with this.

Nov 13 '06 #1
Share this Question
Share on Google+
11 Replies


P: n/a
You can block the painting of the form partially.

Be aware that this can give an elastic effect if you don't do it in short
steps.

Cor

"Ajith Menon" <ko********@gmail.comschreef in bericht
news:11*********************@f16g2000cwb.googlegro ups.com...
>I have created a windows application in which the form needs to be
resized on the MouseMove event. The windows resize function takes a lot
of CPU cycles. And as the resize function is called on the MouseMove,
the form is resized around a 30-100 times in one second. This leads to
a high CPU utilization and all other application comes to a stand
still.

The form does not have any controls i.e. buttons, text boxes etc. It is
completely empty. Its opacity in around 10%.

Now is there any way by which we can reduce all the amount of CPU taken
by the form on resize??

Or can I reduce the form resize calls on MouseMove event. i.e. some way
by which all the mouse move event don't lead to form resize.

Please help me out with this.

Nov 13 '06 #2

P: n/a
"Ajith Menon" <ko********@gmail.comwrote in message
news:11*********************@f16g2000cwb.googlegro ups.com...
[...]
Now is there any way by which we can reduce all the amount of CPU taken
by the form on resize??

Or can I reduce the form resize calls on MouseMove event. i.e. some way
by which all the mouse move event don't lead to form resize.
You don't want to do that. After all, if the user is dragging the form to
resize it, ignoring some of the mouse moves will result in the user not
being able to resize to exactly whatever size they want.

However, as far as the actual problem goes...the CPU consumption is from
redrawing the form every time it's resized. Set the form to not draw during
resizing, and the CPU use will go down (it can't be eliminated, since there
will always be some feedback to the user about the resizing).

If you really think it's necessary, you can disable resize redrawing, but
then handle the resize events yourself and explicitly redraw (invalidate the
form) every so often, as a way of reducing the redraw events.

Pete
Nov 13 '06 #3

P: n/a
Thanks for your immdiate response.
However, as far as the actual problem goes...the CPU consumption is from
redrawing the form every time it's resized. Set the form to not draw during
resizing, and the CPU use will go down (it can't be eliminated, since there
will always be some feedback to the user about the resizing).
How to set the form not to redraw during resize?
Also I got to know the higher processor is due to opacity=10%. The
foreground repaint as well as background repaintis called. In case if
opacticy is 100% background repaint is not called.
>You can block the painting of the form partially.

Be aware that this can give an elastic effect if you don't do it in short
steps.
And what is blocking the painting partially???

Thanks,
Ajith

Nov 13 '06 #4

P: n/a
Hi Ajith,
I suspect that it is the transparency that is causing you to use more CPU
cycles during a resize because transparency require more calculation that an
opaque window. Try making the form opaque when you resize and turn the
transparency back on after the resizing has occured and see if that improves
your situation.

Mark.
--
http://www.markdawson.org
"Ajith Menon" wrote:
I have created a windows application in which the form needs to be
resized on the MouseMove event. The windows resize function takes a lot
of CPU cycles. And as the resize function is called on the MouseMove,
the form is resized around a 30-100 times in one second. This leads to
a high CPU utilization and all other application comes to a stand
still.

The form does not have any controls i.e. buttons, text boxes etc. It is
completely empty. Its opacity in around 10%.

Now is there any way by which we can reduce all the amount of CPU taken
by the form on resize??

Or can I reduce the form resize calls on MouseMove event. i.e. some way
by which all the mouse move event don't lead to form resize.

Please help me out with this.

Nov 13 '06 #5

P: n/a

Mark R. Dawson wrote:
Hi Ajith,
I suspect that it is the transparency that is causing you to use more CPU
cycles during a resize because transparency require more calculation that an
opaque window. Try making the form opaque when you resize and turn the
transparency back on after the resizing has occured and see if that improves
your situation.

Mark.
--
But the requirement is that the form should remain transparent during
resize so that the user can see the items behind the form.
It is something like the user creates this transparent rectangle (i.e.
the form 10% opacity), over other items. All the items that come under
this rectangular region will be copied to the clipboard as .bmp file.

Nov 13 '06 #6

P: n/a
What kind of degredation are you seeing? I set a form to 10% opacity and was
playing a video in my web browser, playing music with a visualization playing
and everything played fine while resizing the form, the CPU was at 100% but
that is okay. I was also running the app in debug mode, my laptop is not
great only 1.8GHz and 768MB of RAM.

Mark.
--
http://www.markdawson.org
"Ajith Menon" wrote:
>
Mark R. Dawson wrote:
Hi Ajith,
I suspect that it is the transparency that is causing you to use more CPU
cycles during a resize because transparency require more calculation that an
opaque window. Try making the form opaque when you resize and turn the
transparency back on after the resizing has occured and see if that improves
your situation.

Mark.
--

But the requirement is that the form should remain transparent during
resize so that the user can see the items behind the form.
It is something like the user creates this transparent rectangle (i.e.
the form 10% opacity), over other items. All the items that come under
this rectangular region will be copied to the clipboard as .bmp file.

Nov 13 '06 #7

P: n/a
Mark R. Dawson wrote:
What kind of degredation are you seeing? I set a form to 10% opacity and was
playing a video in my web browser, playing music with a visualization playing
and everything played fine while resizing the form, the CPU was at 100% but
that is okay. I was also running the app in debug mode, my laptop is not
great only 1.8GHz and 768MB of RAM.

Mark.
I have this transparent form within other application which has many
other forms. The other forms get dynamic data and gets updated
regularly. These other forms of the same application starts degrading
i.e. the dynamic data stop coming on it.

Nov 13 '06 #8

P: n/a
Okay, well that makes sence since the issue will be that the transparent form
and the controls will be using the main UI thread to update, since the form
is resizing and taking most of the processing time the other controls do not
get chance to update.

What you can do is create your transparent form on a new thread and use that
thread as the message pump thread for the transparent form, then you will not
be tying up the main UI thread of your app when you resize. I think this may
work for you, try out something like the following:

private void btnShowForm_Click(object sender, EventArgs e)
{
//Make sure only do this once. This thread is going to create the
//transparent form and be its message pump thread.
Thread t = new Thread(new ThreadStart(CreateOverlayForm));
t.IsBackground = true;
t.Start();
}

//The form which is going to be transparent;
Form transparentForm = null;

void CreateOverlayForm()
{
//Create the transparent form
transparentForm = new Form();
transparentForm.Opacity = 0.1;

//Run the for on this thread creating a new message pump on the
//calling thread.
Application.Run(transparentForm);
}

private void btnHideForm_Click(object sender, EventArgs e)
{
//Only hide the form so we can reuse it later
HideTransparentForm();
}

private void HideTransparentForm()
{
//Make sure we call the hide method in the context of the thread
//that created the form.
if (this.transparentForm.InvokeRequired)
{
this.transparentForm.Invoke(new MethodInvoker(HideTransparentForm));
}
else
{
//This is the thread that created the form, safe to update
this.transparentForm.Hide();
}
}
Hope that helps (or works :-))
Mark.
--
http://www.markdawson.org
"Ajith Menon" wrote:
Mark R. Dawson wrote:
What kind of degredation are you seeing? I set a form to 10% opacity and was
playing a video in my web browser, playing music with a visualization playing
and everything played fine while resizing the form, the CPU was at 100% but
that is okay. I was also running the app in debug mode, my laptop is not
great only 1.8GHz and 768MB of RAM.

Mark.

I have this transparent form within other application which has many
other forms. The other forms get dynamic data and gets updated
regularly. These other forms of the same application starts degrading
i.e. the dynamic data stop coming on it.

Nov 13 '06 #9

P: n/a
Thanks for the solution. I have not tried it yet ... but I think it
should work.
Will try it and get back to you.

Thankyou :-)

Regards,
Ajith

Nov 13 '06 #10

P: n/a
Given the added details you've provided, I'd say Mark's suggestion to run
the form on a different thread has merit. As long as you can keep the
transparent form on a different thread from the forms where the data updates
are occurring, hopefully performance in those other forms won't suffer so
much (and on a dual-proc computer, should not suffer in any noticeable way
IMHO).

That said, just in case here are answers to your other questions:

"Ajith Menon" <ko********@gmail.comwrote in message
news:11*********************@i42g2000cwa.googlegro ups.com...
[...]
How to set the form not to redraw during resize?
Set the ResizeRedraw property to false.
Also I got to know the higher processor is due to opacity=10%. The
foreground repaint as well as background repaintis called. In case if
opacticy is 100% background repaint is not called.
Sure...it makes sense that transparent redrawing would use more CPU than
opaque redrawing. It's not that you have no CPU use in the latter
case...it's just not as much.
>>You can block the painting of the form partially.

Be aware that this can give an elastic effect if you don't do it in short
steps.
And what is blocking the painting partially???
I assume that what Cor was suggesting was to override the OnPaint handler in
the form, and ignore some of the paint events that way. It's pretty much
the same solution that I suggested, except implemented from the other end.
Rather than limiting the paint events (as I suggested), you could simply
ignore some of the paint events (as Cor suggests).

Pete
Nov 13 '06 #11

P: n/a
Hi Mark,

Thank you very much for your solution.

Bye.

Nov 21 '06 #12

This discussion thread is closed

Replies have been disabled for this discussion.