RE: XP increased processor utilization

I stumbled across the following this weekend:
http://www.themssforum.com/MFC/excessive-mouse/

This guy sounds like he has a "very" similar problem and code environment to
what I'm seeing. This led me down the path of checking the OnIdle processing
of the CWinThread class.

I tried overridding the IsIdleMessage in my main app as follows:
  BOOL DDG_STUI::IsIdleMessage(MSG* pMsg)
  {
     if (!CWinApp::IsIdleMessage(pMsg) || pMsg->message == WM_TIMER ||
         pMsg->message == WM_MOUSEMOVE)
        return FALSE;
     else
        return TRUE;
  }

I lifted the bulk of this code from the MSDN CWinThread::IsIdleMessage page
but with a little trial and error (and Spy++) added the WM_MOUSEMOVE to the
condition also. This seems to fix the process utilization issue when the
mouse is moving. It does not resolve the general across the board increase
in processor utilization but I'm guessing the OnIdle processing is still the
culprit.

I couldn't find a response to the question from the link above though it
appears his analysis is fairly accurate. Anyone here have any thoughts on
why XP would handle the SendMessageToDescendants of the WM_IDLEUPDATECMDUI
message so poorly compared to 2K?

Also, any thoughts on the implications of the quick fix I implemented above?
 The documentation I have says the OnIdle updates toolbars (and I don't have
any) and deletes temporary objects. I would think that the triggering of
OnIdle by messages other than MOUSEMOVE should be sufficient to clean up
these temporary objects, but I'm not sure. Finally, any thoughts on just
overridding OnIdle and not calling the base class version? Would those
temporary objects eventually bring my app to a crashing halt if left
undeleted? I'm not sure which temporary objects it is deleting or the
frequency of those objects well enough to make an informed decision.

Shaun