Well, after much struggling and many uses of AQTime profiler, the issue has been solved. The problem was not in the painting, which was where I was looking initially. My first hypothesis (along with most of my other) was that the video card was drawing slowly, but flash somehow kicked up the video acceleration, or something to that effect. But I knew it wasn’t necessarily a hardware problem because a quick MFC test application worked find. So it must be something in our code.
That entire time, I was looking at the wrong end of the pipeline. I was looking at the paint events and other message handlers. The problem was at the message pump end.
Many Windows programs have a message pump that looks like this:
MSG msg;
while (GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
We needed some custom functionality to handle idle-time functions, so our pump looked different:
for (;;)
{
MSG msg;
yield(); // So we don't hog the CPU
if (PeekMessage(&msg, 0, 0, 0, PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
{
doIdleWork();
}
}
What this ended up doing is yielding the CPU between messages, even though we had messages still pending.
Moving the yield to after the idle work did the trick:
for (;;)
{
MSG msg;
if (PeekMessage(&msg, 0, 0, 0, PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
{
doIdleWork();
yield(); // So we don't hog the CPU
}
}
The buttons paint faster, and theoretically, the application should be more responsive. This chunk of code is over 10 years old, written for Windows 95/98. We’ve noticed this problem for a while, but were unable to fix it until now. All because we were looking in the wrong place. In the end, it was a one-line fix.