# WinAPI window taking 50% of CPU when idle

I'm currently working on a game that creates a window using WindowsAPI. However, at the moment the process is taking up 50% of my CPU. All I am doing is creating the window and looping using the code found below:

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
MSG message = {0};
WNDCLASSEX wcl = {0};

wcl.cbSize = sizeof(wcl);
wcl.style = CS_OWNDC | CS_HREDRAW | CS_VREDRAW;
wcl.lpfnWndProc = WindowProc;
wcl.cbClsExtra = 0;
wcl.cbWndExtra = 0;
wcl.hInstance = hInstance = hInstance;
wcl.hbrBackground = 0;
wcl.lpszClassName = "GL2WindowClass";
wcl.hIconSm = 0;

if (!RegisterClassEx(&wcl))
return 0;

hWnd = CreateAppWindow(wcl, "Application");

if (hWnd)
{
if (Init())
{
ShowWindow(hWnd, nShowCmd);
UpdateWindow(hWnd);

while (true)
{
while (PeekMessage(&message, 0, 0, 0, PM_REMOVE))
{
if (message.message == WM_QUIT)
break;

TranslateMessage(&message);
DispatchMessage(&message);
}

if (message.message == WM_QUIT)
break;

if (hasFocus)
{
elapsedTime = GetElapsedTimeInSeconds();
lastEarth += elapsedTime;
lastUpdate += elapsedTime;
lastFrame += elapsedTime;
lastParticle += elapsedTime;

if(lastUpdate >= (1.0f / 100.0f))
{
Update(lastUpdate);
lastUpdate = 0;
}
if(lastFrame >= (1.0f / 60.0f))
{
UpdateFrameRate(lastFrame);
lastFrame = 0;
Render();
SwapBuffers(hDC);
}
if(lastEarth >= (1.0f / 10.0f))
{
UpdateEarthAnimation();
lastEarth = 0;
}
if(lastParticle >= (1.0f / 30.0f))
{
particleManager->rightBooster->Update();
particleManager->rightBoosterSmoke->Update();
particleManager->leftBooster->Update();
particleManager->leftBoosterSmoke->Update();

particleManager->breakUp->Update();
lastParticle = 0;
}
}
else
{
WaitMessage();
}
}
}

Cleanup();
UnregisterClass(wcl.lpszClassName, hInstance);
}

return static_cast<int>(message.wParam);
}


So even when I am not drawing anything when the window has focus it still takes up 50%. I don't understand how this is taking up so much system resources.

Am I doing something wrong?

Any help would be much appreciated, thank you!

• This would be better at stackoverflow.com because it's not truly game development related despite the fact that you are trying to make a game with it. – Ricket Jan 29 '11 at 17:56

When focused, your program executes the loop continuously. It uses all of the available CPU resources given to it by the OS because you have said "I must use all of the available CPU resources given to me by the OS" -- you don't have any statements -- such as a call to Sleep() or using GetMessage() instead of PeekMessage() -- that will block your thread and tell the OS you wouldn't mind being switched out now.

Note that I'm not suggesting Sleep() or GetMessage() are proper solutions, per se, only that using them would cause your apparent CPU usage to drop. It isn't necessarily a problem that your program asks for as big/frequent of a timeslice as you can get from the OS. Games typically do this, for example. As long as you play nice when you're not the foreground app by reducing processing or drawing, et cetera, which it looks like you are doing, you should be fine.

• updated my code snippet. – henryprescott Jan 29 '11 at 18:14
• I get what you're saying, however I'm a bit miffed that my application is occassionally using 94% when particles are created. – henryprescott Jan 29 '11 at 18:17
• yes I have dual core. – henryprescott Jan 29 '11 at 18:49
• Even the updated code is still not sleeping or waiting on anything, which is what you must do, if you want your CPU utilization to drop. – user744 Jan 29 '11 at 19:52
• At the moment it seems to always use 100% of a core (50%), but then it goes above 50% when I start doing other things. How does it spread over 2 cores like that? I thought it would instead reduce the time it waits for messages, (50%) - (game engine usage%) – henryprescott Jan 29 '11 at 21:20

If you don't respond to paint messages, windows will keep spamming your window with paint messages, which probably takes a bit of cpu time. This is my guess. I'm not entirely certain, though.

• WM_PAINT is generally only sent once and only when there are no other messages in the queue (although DefWindowProc, if called, will validate the update region and potentially allow more to be enqueued). Failure to handle it oneself can cause problems, but shouldn't cause one to peg a core like this. – user1430 Jan 29 '11 at 18:06