Basically, we use DXDocking as a tabbed environment along with the ribbon control. Clicking a button in the ribbon control initialises a new view/control and adds it to a tab in the dock.
The issue is that following the button click it appears to take a very long time to show the new control (up to 5s depending on machine speed). However, on subsequent clicks, the new control will open very quickly (<1s) (each click creates a new control(), so it isn't reusing anything in my code).
From my reading on Stackoverflow and other places, this sounds like an issue with loading the theme files and then caching them.
I found a possible solution here: http://www.devexpress.com/Support/Center/p/B201967.aspx, but this is pretty nasty (it involves having a hidden window loaded with dx controls loaded at startup that can force the system to start caching the theme files). It also didn't really seem to achieve much for me.
My docking environment is a modular system where modules are loaded on startup using MEF. Ideally I would want to inspect each module on startup for a list of dx controls that it uses and then silently start pre-caching the themes for them on a background thread.
Any ideas on how I could achieve something like this?
Poor load performance of controls
Answers approved by DevExpress Support
Hello,
We decided to revisit the records related to the startup performance in our knowledge base. In the latest version (currently, it is v23.1), we recommend using tips from the following help topic to improve the startup performance in a general case:
Support, Debug, and Troubleshooting > Reduce the Application Launch Time
Additionally, please refer to the following blog post in our WPF Team Blog:
9 Tips to Reduce WPF App Startup Time
In v23.1, we also further improved the startup performance for DevExpress controls and introduced a new set of lightweight themes. See what's new in the corresponding post:
Please feel free to create a separate ticket if you encounter a performance issue with our components.
Hi David,
Thank you for your inquiry.
First, let me describe our theme mechanism and why our controls are slow when used for the first time. In our controls we use a mechanism that loads necessary resources for our controls on demand. If your application has a reference to DevExpress.Xpf.Grid, but you do not use GridControl, resources for GridControl will not be loaded. However, when you show any of our controls for the first time, resources for this control are loaded. The delay you see is related to this fact. By the time you show the loaded control again, resources are already loaded. Thus, the control appears faster. Note that the first display of any control requires more time, than the second one, because WPF builds a Visual Tree. With our controls you should not have any delay, because we have improved this behavior.
As a workaround, you can transform this delay to the application startup: show the Splash screen and all our controls that are not visible when the main window is shown. A similar mechanism is described in the B201967 thread that you have found.
Looking at the detailed description of your scenario, I suggest a different way:
What do you think if the splash screen appears while the MEF module is loading? I mean that you can show the waiting screen before the MEF module is shown and hide this indicator when the MEF module becomes hidden. I have attached a sample to demonstrate this approach.
Please let me know whether or not this approach suits your requirements.
Thanks,
Alexander
Thanks for your response.
If I understand your suggested solution correctly: you are suggesting that I show a loading indicator for each view as I open it and subscribe to the loaded event of the root element of each view to tell the loading indicator when to stop? I will try and set this up (a loading indicator is better than hanging) but I was really looking for a way to make the application a bit more responsive.
I completely understand that you load resources on demand, this is, of course, a very sensible thing to do.
However, for some views the loading of these resources is really very slow. For example: if I have a ribbon with a lot of different editor controls on it.
At the moment it sounds like the only way to pre-cache is using the technique described in the other thread where a window is shown and then hidden off-screen (but this is quite messy).
Does this mean that the pre-caching of resources *has* to occur on the UI thread? So no matter what there will be blocking?
Ideally, it would be great to be able to provide a list of types to a pre-fetcher that could run in the background to pre-cache some of the resources. e.g.
DxCache.PreLoad(typeof(TextEdit), Theme.Office2007BlueName);
DxCache.PreLoad(typeof(GridControl), Theme.Office2007BlueName);
etc.
Then, with when I load modules with MEF on startup I can inspect each module for a list of DX controls and add them to the list of the items to pre-cache on another thread.
Hello David,
Thank you for your feedback. We have researched this issue within other threads and have not found a way to load all necessary controls/editors' visual elements without showing them. It looks like WPF does not provide such a feature. Components should be addressed for showing on the screen to load themselves completely. If you have an idea, feel free to post it here.
Thank you, Marina
Thanks for your help.
I'll post on some forums and reply here if I get anything back.
David,
Thank you for your feedback. You are free to reactivate this issue if you find something interesting.
Thank you, Marina