I faced this issue in the past in a win32 app and again with WPF.

The solution i came up with is this:

• Paint / Invalidate requests are only stored (only set a needs_painting flag), never attended immediately
• There is a timer in your graphics window that ticks every few MS (depending on desired max frame rate, for 30fps will be 33ms, 16ms for 60fps) and basically does nothing (it is to force frequent messages into the msg queue)
• On the WndProc (window message processing method) first you check if paint is needed, then you paint. To check if paint is required i have this conditions: if there was a paint request (paint pending flag is true) and amount of ms since last paint is same or more than 1000/(your desired frame rate).
• As well its a good practice to set some extra room for other things to happen, so its good practice to have Adaptative fps: decrease the FPS if time to paint is bigger than the fps: (paint time + 3-4 ms) < (1000 / desired fps)

This will have you app having quite consistent frame rates even if mouse moves like crazy.

For WM_TIMER you can do something similar (but im guessing that with the above your issue will be solved).