Description
Description
When you hold down a key while you resize a WPF window the resize messages (and/or the mouse messages triggering them) pile up and get processed delayed, causing a rubbery-like effect where the resize starts to lag the actual mouse position significantly, but follows the original mouse trajectory instead of targeting the most recent mouse position.
I cannot explain this any better unfortunately, but this happens with the Visual Studio window too for example. Begin resizing, hold a key down, then resize back and forth or in a circular motion. The window will start to lag the mouse but will follow the path the mouse originally took. If you do the same without a key held down this does not occur.
This seems to be indicative of Windows internal mousemove coalescing/merging behavior to be interfered with, causing the mousemove messages to pile up in the message queue.
Reproduction Steps
Begin resizing a non-trivial WPF app (the Visual Studio window itself for example), hold a key down, then resize back and forth or in a circular motion. The window will start to lag the mouse in a rubbery-like fashion, following the original trajectory of the mouse move but with significant and increasing delay.
It is recommended to set the Windows keyboard repeat rate to fast to better trigger the effect.
Expected behavior
The window resizing should try target the mouse's most recent position (as much as possible), not the position/trajectory where it was seconds ago.
Actual behavior
Rubbery-like resizing effect where the resizing follows the historical mouse trajectory instead of targeting the most recent mouse position.
Regression?
No response
Known Workarounds
If I use a LowLevel Keyboard hook (WH_KEYBOARD_LL) to prevent WM_KEYDOWN messages being processed while the resize is in operation, the effect can be mitigated. But this is only for debug purposes and to verify that it is the repeated WM_KEYDOWN messages that somehow cause this issue.
Impact
We have a docking feature in our app that the user can trigger while holding down a specific key while moving the window. When reaching the dock location we resize the window to show a preview of the how the docked window would look, but the docked preview size is continuously being adjusted as the user drags the mouse (making it bigger/smaller). And because the user is holding down a key during this operation, we get this rubbery effect.
Configuration
No response
Other information
Interference of WM_MOUSEMOVE, WM_KEYDOWN and maybe the WPF internal "DispatcherProcessQueue" message somehow, preventing WM_MOUSEMOVE coalescing/merging in the Windows internal message queue.