Consider a simple win32 application that creates a single OpenGL frame
window using the following windows procedure
LRESULT CALLBACK WndProc(
HWND hWnd,
UINT message,
WPARAM wParam,
LPARAM lParam)
{
PAINTSTRUCT ps;
HDC hdc;
HGLRC hRC;
PIXELFORMATDESCRIPTOR pfd =
{
sizeof(PIXELFORMATDESCRIPTOR), 1,
PFD_DRAW_TO_WINDOW | PFD_SUP****T_OPENGL |
PFD_DOUBLEBUFFER, PFD_TYPE_RGBA,
24, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0,
32, 0, 0, PFD_MAIN_PLANE, 0, 0, 0, 0
};
switch (message)
{
case WM_CREATE :
hdc = GetDC(hWnd);
SetPixelFormat(hdc, ChoosePixelFormat(hdc, &pfd), &pfd);
hRC = wglCreateContext(hdc);
wglMakeCurrent(hdc,hRC);
SetTimer(hWnd,1,15,NULL);
break;
case WM_TIMER :
InvalidateRect(hWnd,NULL,FALSE);
break;
case WM_PAINT:
hdc = BeginPaint(hWnd, &ps);
glFinish();
SwapBuffers(hdc);
EndPaint(hWnd, &ps);
break;
case WM_DESTROY:
PostQuitMessage(0);
break;
default:
return DefWindowProc(hWnd, message, wParam, lParam);
}
return 0;
}
According to the windows task manager on my dual core machine both
processors are 100% utilised while this window is displayed
When I comment out the call to glFinish the CPU usage drops from 100%
to exactly 50% suggesting that at any given time one processor is
fully occupied within SwapBuffers(). Does this suggest the OpenGL
driver is using a spin lock?
If the timer period is increased from 15 msec to 17 msec the total
processor activity drops from 100% down to about 3%. Presumably this
has something to do with the synchronisation with the screen refresh.
Is it reasonable for the OpenGL driver to consume the CPU like that?
|
