Slow render performance with

Docking/MDI for WPF Forum

Posted 2 months ago by Peter Jorgensen
Version: 19.1.0681
Platform: .NET 4.7
Environment: Windows 10 (64-bit)
Avatar

We're seeing a noticeable change in performance of our application when using DockSites. Our current production code is seeing this in 2016.1, but while trying to troubleshoot I also tried with 2019.1 and am seeing the exact same delay when switching our presently displayed ViewModel to one with a DockSite defined for it.

Is there anything we can do to pre-cache the DockSite? It adds as much as a full second to the time it takes to switch views, confirmed by removing the DockSite from the view we are using and utilizing the Visual Studio Application Timeline to measure perofrmance of specific components being drawn.

Comments (5)

Posted 2 months ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Peter,

I'm sorry you're having trouble.  Can you explain more about your application's docking window setup and how you are populating the dock site?  The more detail about the scenario that you provide, the more we can understand how the product is being used.

And are you specifically referring to the time between clicking an unselected MDI tab and waiting for its content to appear in place of the previously-selected MDI tab's content?


Actipro Software Support

Posted 2 months ago by Peter Jorgensen
Avatar

Our application is using MVVM. The main window on launch is a splash screen where users can select one of several options, upon opening a "document" (best analogue for what's happening) it changes to a new view which includes the DockSite with one or more ToolWindows and our main editor view. We're not using MDI, just the tool windows for right now. 

The delay we are seeing is in going from that splash screen into the main editor view. 

Using Visual Studio's application timeline, we've found that the DockSite is adding a noticeable amount of time to the render of the view. Here's a screenshot of the timeline with the DockSite (just under 1.7 seconds): https://i.imgur.com/xQMdTI6.png

And a screenshot without the DockSite (860ms, almost a full second less): https://i.imgur.com/aTWjb6X.png

Understandably, the DockSite adds quite a few visual elements, so I'm just hoping for a way to pre-load the visual elements to speed up the delay of drawing the new view.

Posted 2 months ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Peter,

One thing that could contribute is that .NET loads assemblies on the fly as they are needed.  So the first time you reference anything related to docking windows, it's having to load up our Shared and Docking assemblies at a minimum.  If you use other controls from us in that same UI, it's having to load those assemblies as well.  That process should go relatively quickly though.  One way to minimize that would be to reference a type from those endpoint assemblies back in your splash screen to get them to preload.

Beyond that, time would be taken doing layout of the tool windows and their content.  I wouldn't expect a simple tool window layout itself to take much time but if the content in the tool windows is complex, that could certainly add time.  You could try and load up a stub tool window layout initially where the tool window contents are empty and see how much of a time difference there is.  Or maybe load all that up in your splash ahead of time, and then just set it and initialize the contents of each tool window when the "document" option is chosen.


Actipro Software Support

Posted 2 months ago by Peter Jorgensen
Avatar

Unfortunately, pre-loading the DLLs by creating instances of the components (either directly on the splash screen view or just by instantiating them in the code-behind and never drawing them) doesn't seem to make a difference in the time spent on Layout and Parsing the main view. The two tool windows that load with a document are fairly light on layout (they take around 150ms, looking at the application timeline). 

Posted 2 months ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Peter,

I might suggest using a good .NET profiler like dotTrace and run it in line-by-line mode so that you can see exactly what execution call tree is causing the slowdown.  That should give you a lot more detail.


Actipro Software Support

The latest build of this product (v2019.1 build 0682) was released 29 days ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.