lower CPU usage when resizing
Author
Hi,
I've developed a program and i've been trying to find the cause of a few problems, and i've discovered that it's giving me 100% CPU usage after about a minute of running. The program isnt really that complicated so it shouldnt be doing this.
BUT i noticed by accident that if i click the edge of the window to resize but dont release, the usage drops to about 50%, then shoots back up when i let go. The window is a plain white window, no icons buttons or anything just a plain white background from a 'your first win32 app' example.
I cant think why though. There has always been something wrong with my computer though, because the CPU temp jumps really high when under not huge amounts of work.
But can anyone shed some light as to why holding on when resizing makes such a difference?
Thanks.
100% CPU usage is caused by your program not letting Windows to process other tasks. If you have an unlimited loop somewhere in your program (which is very likely since it's GUI), you should somewhere in the middle of the loop let Windows to handle other tasks, although however, a correct handling of your program messages should automatically handle this. If all else fails, try Sleep().
Author
There's the unlimited loop that uses PeekMessage within it, but there's no other work there. All the work done is from an interrupt timer called every 10milliseconds through timeSetEvent. So i would have thought i'm letting windows do everything it needs to since there is a message handler there?
Thanks for the reply.
Thanks for the reply.
If there's an infinite loop that's always going around and around and around and around, without ever pausing, of course you're going to have 100% CPU utilization.
Author
yeah that does make sense, but its just this:
and this is what i've seen in pretty much every 'learn win32' book and tutorial. Is this the wrong way to do it?
//Message handler:LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam){ // Process the message switch (msg) { // Check for key press case WM_KEYDOWN: { // Check for ESC key press if (VK_ESCAPE == wParam) { // Destroy the window DestroyWindow(hwnd); break; } }break; // Check for window closing case WM_CLOSE: case WM_DESTROY: { // Post a quit message on the queue PostQuitMessage(0); break; }break; default: { // Handle any unprocessed message return DefWindowProc(hwnd, msg, wParam, lParam); }break; } return(0);}// main loop:while (1) { // Check message queue if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) { // Is it a quit message? if (WM_QUIT == msg.message) break; // Translate and dispatch message TranslateMessage(&msg); DispatchMessage(&msg); } }and this is what i've seen in pretty much every 'learn win32' book and tutorial. Is this the wrong way to do it?
Consider a long, involved infinite loop to be like counting to a million, over and over and over again. Consider a tiny infinite loop to be like counting to three, over and over and over again. Now, tell me: Do you spend any less time counting when you count to three over and over again?
To fix this issue: Don't use PeekMessage. Use GetMessage, which will pause until a message is actually received. Of course, there are situations where you don't want to pause.
To fix this issue: Don't use PeekMessage. Use GetMessage, which will pause until a message is actually received. Of course, there are situations where you don't want to pause.
PeekMessage checks to see if there is a message in the queue. It does not block, so whenever you do not have a pending message your message handling loop is equivalent to:
while (1)
{
}
which is a busy waiting loop in which the processor will continuously be checking that 1 is not false (which it isn't and never will be). The alternatives are to either use GetMessage instead of PeekMessage, which waits for a message in a non-busy manner before returning, or to add a call to Sleep in your loop to give up the processor to other processes for a time.
Enigma
while (1)
{
}
which is a busy waiting loop in which the processor will continuously be checking that 1 is not false (which it isn't and never will be). The alternatives are to either use GetMessage instead of PeekMessage, which waits for a message in a non-busy manner before returning, or to add a call to Sleep in your loop to give up the processor to other processes for a time.
Enigma
Author
Beautiful....
GetMessage works perfectly. I guess peekmessage is for people who like the old way of doing things?
If you knew you would need complete processing power is it ok to use peekmessage or should you always be as friendly with windows as you can?
Thanks alot for your help guys.
GetMessage works perfectly. I guess peekmessage is for people who like the old way of doing things?
If you knew you would need complete processing power is it ok to use peekmessage or should you always be as friendly with windows as you can?
Thanks alot for your help guys.
PeekMessage isn't older; it's just a different function. It's used in situations where you don't want your control-flow to be fully event-driven. Games use a PeekMessage-based loop quite often. That's because things in a game are happening in realtime, not just whenever you click the mouse.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
