Higher CPU Utilization on Windows form resize

[Ajith Menon]

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.

[Peter Duniho]

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********@gma il.comwrote in message
news:11******** *************@i 42g2000cwa.goog legroups.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

[Ajith Menon]

Hi Mark,

Thank you very much for your solution.

Bye.