Migrating from AvalonDock: performance problem

Docking/MDI for WPF Forum

Posted 10 years ago by Dmitry S. Arestov
Version: 13.2.0591
Platform: .NET 4.0
Environment: Windows 7 (64-bit)
Avatar

Hello,

I am currently evaluating Actipro Docking, as I want to migrate to it from AvalonDock. In my application, there is an abstraction layer that isolates application logic from docking framework. So I simply added another implementation that uses Actipro instead of AvalonDock, and got the app working, but there is an issue.

In the app, I have two tool windows docked to the left. And switching between them in Actipro takes too much time (about a second or two). I have made an investigation and found out that the delay depends on content's visual tree complexity. That sound reasonable, but with AvalonDock I don't get this performance issue.

I generated a TreeView with a huge number of items. In this case both Actipro and AvalonDock are performing switching slowly. But it seems that Actipro docking framework begins to freeze with less number of items.

So the question is - what should I do? Is this a bug which you will fix sooner or later, or am I supposed to simplify my layout somehow?

Thanks in advance.

Comments (3)

Posted 10 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Dmitry,

I don't think we are doing anything special in that case, we are just swapping the tool window content for a tool window in and out of a ContentPresenter, the same way TabControl and TabItems work.  Quick question though... are you using MVVM or are you explicitly defining controls within your tool windows?


Actipro Software Support

Posted 10 years ago by Dmitry S. Arestov
Avatar

I do not use MVVM at the docking implementation layer. Here is my layout:

    <dock:DockSite Name="dockman" ToolWindowsHaveOptions="False" ItemContainerRetentionMode="Wrapped">
        <dock:SplitContainer>
            <dock:ToolWindowContainer Name="leftContainer">

            </dock:ToolWindowContainer>

            <dock:SplitContainer Orientation="Vertical">
                <dock:ToolWindowContainer Name="topContainer">

                </dock:ToolWindowContainer>

                <dock:Workspace>
                    <dock:TabbedMdiHost dock:Workspace.MdiTypeKey="{x:Type dock:TabbedMdiHost}"/>
                </dock:Workspace>

                <dock:ToolWindowContainer Name="bottomContainer">

                </dock:ToolWindowContainer>
            </dock:SplitContainer>

            <dock:ToolWindowContainer Name="rightContainer">

            </dock:ToolWindowContainer>

        </dock:SplitContainer>
    </dock:DockSite>

 As you can see, I defined four Toolwindow Containers beforehand to be able to add toolwindows programmatically at runtime. This is how I do this:

wnd = new ToolWindow(dockman, name, toolWindow.Title, null, toolWindow);

ToolWindowContainer container = leftContainer;
                    switch (toolWindow.RecommendedDockSide)
                    {
                        case DockSide.Left:
                            container = leftContainer;
                            break;
                        case DockSide.Right:
                            container = rightContainer;
                            break;
                        case DockSide.Top:
                            container = topContainer;
                            break;
                        case DockSide.Bottom:
                            container = bottomContainer;
                            break;
                        default:
                            container = leftContainer;
                            break;
                    }
                    wnd.Dock(container, Direction.Content);

What can you say about this?

Posted 10 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Dmitry,

This might be unrelated to the main problem, but what you have here isn't a good setup for the layout.  Docking window containers are transient objects that should only be created/destroyed as needed by our internal code.  The only exception being that you do need them in cases where you set up your initial XAML to contain tool windows also defined in XAML.  You should never created named references to containers though, since eventually those will go out of scope and not be used any more after serialized layout loads or just end users moving things around.

Basically you should alter your DockSite to just have the Workspace/TabbedMdiHost inside of it directly (remove the SplitContainers and ToolWindowContainers).  Since you aren't defining any tool windows in XAML, you shouldn't have any tool window containers defined.  Then alter your code-behind to dock against the DockSite (instead of a container). 

You can also improve its logic to see if there is a horizontally-oriented SplitContainer as the DockSite's first child.  If so, dock into that for the top/bottom cases.  That way it mimics what you were trying to do with your code here, but is more dynamic based on what the layout is at the time that code executes.


Actipro Software Support

The latest build of this product (v24.1.1) was released 2 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.