8000 Resizing a window while holding a key down causes weird delayed/rubbery resizing · Issue #10843 · dotnet/wpf · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
Resizing a window while holding a key down causes weird delayed/rubbery resizing #10843
Open
@ignus2

Description

@ignus2

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0