Lagging KeyEvents

[FarokkoFokko]

I have run into the following issue after migrating to AvalonDock.

I have a ListView with many items, often times more than a million. As a result PageUp and PageDown are used a lot to scroll through the list. There is some functionality behind the OnSelectionChanged event, to update certain other controls on the screen.
Typically a user holds the PageDown (Or PageUp) key down to continue scrolling and will release the button after reaching a certain item. Now that I am using AvalonDock, the listview keeps scrolling for a considerable amount of time, after the key was released.

I have isolated the issue, by modifying the 'TestApp' sample project in the Avalondock repository. Here I can see that when I do not include the dockingManager in the MainWindow, everything works as expected, but when the sample DockingManager is a part of the MainWindow, I get the lagging scrolling behavior.
In this test I have:

• A listview bound to an ObservableCollection of strings, containing 10,000 strings.
• The listview shows about ten items at a time.
• I press and hold the pagedown key.
• I release the Key when I see item ~3000.
• I have a a wait loop waiting for about ~200 ms with every OnSelectionChanged event

If useful, I could commit these changes to a branch or create a pull request for you to check out.

[Dirkster99]

I am not sure what to do with this - even if I had a demo program to verify your problem I am not really sure how to fix it. The lag you see might occur because WPF requires a few extra milliseconds to find the keyboard focused element in the Visual Tree (?) or it might be something else.

I am not aware of any special keyboard handling that could be reviewed and optimized inside AvalonDock but sine this is open source feel free to analyze your problem and suggest a PR if you think you found a solution. Thanx Drk

[FarokkoFokko]

Thanks for your reply Dirk.
I was hoping you had some ideas with what this could have to do.

It's not a few milliseconds, but rather seconds. That is: the application keeps handling keydown events seconds after the key was released. Without AvalonDock on my window this does not happen.

I spent some time going into the AvalonDock source and I have the feeling it may have something to do with the use of HwndHost and the Win32 compatibility. Does that ring any bells, perhaps?

For example: If I comment out the call to "SetupAutoHideWindow();" in method "DockingManager.DockingManager_Loaded()" I do not have the issue. This also result in a single rootItem in the 'Live Visual Tree' window during debugging.
If I then pull out a window from the application into a floatingwindow, I get two more rootItems, one of which is a HWND item. After doing that, the lagging key event behavior is back.
If I then close that floating window, I'm back at a single rootItem and the lagging behavior is gone again.

Any idea or suggestions would be highly appreciated.

[Dirkster99]

Hi @FarokkoFokko the use of HwndHost and the Win32 APIs are not really ringing a bell for me but the Wind32 part seems to be hacky in several ways and I am not the only one having trouble with it :-(

So, from what you write I could only recommend using the:

• LayoutDocument.CanFloat property and
• LayoutAnchorable.CanFloat property

to disable the use of FloatingWindows. I know thats really just a workaround solution but I am really not able to recommend anything else. I would be happy to help adjusting the Win32 API if someone with a better knowledge/insights would suggest more optimal solutions ...

[FarokkoFokko]

Hey Dirk,

Yeah the Win32 code is not the best part of the AvalonDock codebase :)
I will give it some more thought and try some things. The lagging keys are a showstopper for me, but the AvalonDock functionality is a great upgrade for my app, so I really want to use it.

If I would follow your suggestion I will also need to comment out the AutoHide stuff as that always gets instantiated at initialization. That mean I would need my own fork of the AvalonDock as well. Which is doable, but not ideal.

Thanks a lot for your time and thoughts.