Why is Tab Rendering slow in demo

Hi Doug,

When a tab is first selected, part of the time is probably the control being loaded by WPF and the other part is us calculating the group variants for that tab.

But please note that when running in Visual Studio debug mode, any sort of rendering will run slower than what your end users see. There always is a noticable difference between opening the sample project in VS and running via F5 versus using Windows Explorer and running the application externally outside of VS. This is because VS injects debugging code which slows down the WPF rendering phase.

So when judging performance, you should really run the app from Windows Explorer to see what it really runs like.

But if you still would like to preload tihs, perhaps what you could do is run through and select each tab one at a time to kick off the initialization code. You could do this before the window is displayed to the user and while a splash screen is up.

I did as you suggested and ran the xbap Live demo and the same behavior is observable.

I know I amy be sounding picky but a more reponsive App is one of our requirments moving to WPF.

I have used a competing WPF ribbon that doesn't seem to suffer this delay. I prefer your Ribbon over theirs since you have implemented the "Live Preview" feature.

Could you publish a code snippet that implements your preload suggestion to your demo so I can run some tests to evaluate the work around.

Thanks,
Doug

There still will be some slowdown but it will be much faster when no debugger is attached. However your suggestion is a good one but let me first explain why the slowdown is there.

Our resizing model is much better than our competitors and allows for exact reproduction of how office functions. See this page for a sample:
http://www.actiprosoftware.com/Products/DotNet/WPF/Ribbon/RibbonResizing.aspx

Our model gives you total control over variants at both the group level and at layout level inside of groups so you can set where and when controls should appear differently based on width. Our competition's resizing model is not nearly as robust. So again with ours, you can do anything Office can do in regards to layout and adjusting that layout as resizing occurs.

To support these advanced features, there are some calculations involved. And those typically take place when a Tab is first loaded. This is part of the delay you see the first time you select a Tab.

Now onto what we can do. I like your idea of preloading the calculations. Perhaps we can kick in the preload in our code so that you don't need to do anything. Do you think that would make sense or should be make this preloading an option and default it to true?

BTW, I did test the preloading here with some internal code and it does function very responsively the first time you select a Tab, as you were hoping for.

Kudos for your quick responsive support.

I like your idea of the built in preloading and "enabled" option default.

If "startup is slightly delayed" vs. "Initial tab selection is delayed", I will take the startup delay every time since it would be more transparent to the user.

Hi Doug,

This is now complete for the next maintenance release. A Ribbon.IsTabGroupVariantPreLoadingEnabled property has been added which is true by default.