Switching between documents slow

[matko238]

Hi,

I'm having an issue with LayoutDocument inside LayoutDocumentPane. When I add multiple LayoutDocuments inside the DocumentPane and if content of that LayoutDocuments has many UIElements (for example, tens of thousands of elements) switching between them is extremely slow - it seems that when clicked/switched to, LayoutDocument recalculates something with it's child controls, including Canvas. Switching is super fast if hosted controls inside LayoutDocument are simple, with normal number of child items.

Also, docking from floating position back to "pinned" state also sometimes takes long time, same like switching between documents like above.

Any way to bypass this behavior? Users will have 10-15 documents open like that in "tabs" so switching between them should be fast.

[matko238]

More info - simply clicking on tab header (with document name and close button) is enough to freeze everything. How long it will stay unresponsive is directly related to number of child controls or UIElements.

[Dirkster99]

Hi,

thanks for sharing these details. It sounds like you are having trouble with the number of UI Elements that can be handled with WPF. I encountered and described a similar problem in a related CodeProject article: Space Navigator A Journey into WPFs Display Sub System.

In an ideal world we should off course be able to update a LayoutDocument inside a LayoutDocumentPane only once when switching from one document to the other. But the reality of:

• Visual Trees
• UI Thread usage instead of async background tread usage,
• and other technical details is a different one.

Its at least extremelly difficult to fix this in AvalonDock without breaking something else (like updating the UI under some exotic condition).

1. I would really recommend thinking about an optimization of your documents UI (caching, Virtualization etc).

2. Alternatively, given that you have a good understanding of AvalonDock and can contribute a PR that shows how UI updates can be optimized for your situation, I'd be willing to look into it and see if it does not break other things through testing.

What do you think about optimizing your document? Have you tested this with:

• a limited number of UI Elements in a document or
• a without always completing all all UI updates in all UI Elements?

If yes, and you find that your freezing dissappears it could really be worthwhile looking into 1).

[matko238]

Thank you for your reply - I have more information that should help.

I've changed number of elements inside canvas - how long it will take to switch documents depends on number of canvas elements - currently, with 8k switching takes second-two and it increases with number of elements inside canvas. Issue is, all other operations (minimize, resize, open outside AvalonDock (inside normal window) are not impacted by number of canvas elements that severely.

But i discovered something else:

For some reason, LayoutDocumentPaneGroup has 16+ million child objects and they all are of type LayoutDocumentPane. I have only about 8k elements in Canvas (one of Documents inside dock panel) but for sure I didn't load 16+ million object. I guess its some kind of error which occurred while I was moving/docking document. See attached image

[edit] - additional details

[matko238]

After much tinkering, initial problem of slow switching is solved by "virtualizing" tab control which is responsible for hosting documents. I've used following solution https://stackoverflow.com/a/37171847/1286216 and changed LayoutDocumentPaneControl and LayoutAnchorablePaneControl base to this newly created TabControlEx. I would love to submit PR but I'm not that well versed in git (we use TFS). :)

Also, it should be added as an option of DockingManager whether to use virtualized tab control or not, since some people might not like it.

Anyway, I'm closing this issue and thank you @Dirkster99 for assisting in rubber ducky programming. Time after time, it proves its invaluable for solving issues.

[Dirkster99]

Hi,

it looks like you discovered 2 issues - the issue with the PropertyChanged might be a memory leak that occurs during switching/re-ordering tabs. I've already tried to close some of these issues:

• #128 fixing memory leaks

but there might be more and its really hard to solve some of these because a solution might cause another side effect leading to another bug :-( which is why I had to roll-back part of the above fixes in this commit Undoing LayoutGridControl changes commited on 2020-02-22 .

A pull request with GitHub is really easy and can be done through the web site and VS only:

1. Create a Fork from the AvalonDock repository
   

   This should create a repository called matko238/AvalonDock.

2. Clone the forked repository to your desktop PC (I prefer using a simple app called GitHub Desktop) and use the Clone button in the Web-Interface (this requires GitHub Desktop to be installed before cloning but it should also work via the VS option - I just have not done this with VS yet).
   

3. Use Visual Studio to edit the cloned copy and commit changes via the Team Explorer (Tool Window) to your forked repository matko238/AvalonDock.

4. Once you are happy with your changes, and they are commited to your forked repository, you can create a Pull Request via the web interface options in your repository:
   

Verify the branches shown and click Pull-Request:

Use the next dialog to describe your changes in a human-readable format and click Create pull request to make the PR visible under Pull Requests in Dirkster99/AvalonDock:

This lengthy explanation makes it seem difficult but its really simple since you can do it all with the web interface and VS and I just tried to describe/screenshot all details hopping that its easy to follow. Please let me know if you have additional questions or a contribution :-)

[matko238]

Thank you very much for those instructions, I'll try to push this change as soon as I test everything. Again, option should be added later on to disable this behavior if someone still wants to controls/documents be unloaded (removed from Visual tree) and loaded again when switched back to that document.

Performance is much better now (switching is almost instant) but memory leak is another issue someone more experienced should tackle.