Forum

Hi !

I’m gonna take as a reference the RibbonBarMDI sample.Here is what i’m facing on my home 3.4Ghz dual core CPU :

Hovering on the Font ribbon and Paragraph ribbon field, they update very slowly the state of the buttons under the mouse cursor, it takes a little bit under 1 sec to get updated, and 50% of the power of CPU. I think you can understand that is way too much, the user experience is not real-time... Looking at how the CPU react according to where you hover the cursor make me think about of a cache problem, like it would be rebuild again and again.. hope that can help

But when i use the reduce Ribbon feature, then the performance on those 2 ribbon fields get way better ! nearly realtime... hope that can lead to some clue...

I’ve tryed some samples from other technologies (read other middlewares), they ’re behaving in realtime with a maximum of 20% of the CPU power being used.

I really think this reccuring UI performance can be adressed.

Of course the sample has been build with this in the core :

CExtPopupMenuWnd

::g_bMenuWithShadows = false;

CExtPopupMenuWnd::g_bMenuShowCoolTips = true;

CExtPopupMenuWnd::g_bMenuExpanding = false;

CExtPopupMenuWnd::g_bMenuHighlightRarely = false;

CExtPopupMenuWnd::g_bMenuExpandAnimation = false;

CExtPopupMenuWnd::g_DefAnimationType = CExtPopupMenuWnd::__AT_NONE;

CExtPopupMenuWnd::g_nDefaultFadeOutAnimationStepCount = 0;

CExtPopupMenuWnd::g_nDefaultFadeOutAnimationEllapse = 0;

CExtPaintManager::g_DefAnimationParametersNormal

= CExtPaintManager::g_DefAnimationParametersSlow

= CExtPaintManager::g_DefAnimationParametersVerySlow

= CExtPaintManager::g_DefAnimationParametersVerySlowAndSmooth

= CExtPaintManager::g_DefAnimationParametersEmpty;

Now when i use the same sample at work on a 2.4GHZ Quad core, the sample reacts as it should be that is : in real-time. without the preceding performance params...

Have you got any clue about what’s happening ?

I’ve red that you were working on performance monitoring, have you find anything usefull ?? if yes have it been integrated in the 2.83 ?

Thank you very much for understanding how important this performance issue is. I’m looking forward to hear how you guys can really improve thisor gining us the methode to do it ourselves (DDB vs DIB ??)

Thank you very much !

We forgot to add that the problem only occures under the Office 2007 themes

The ribbon bar’s performance can be tested using our RibbonPage sample application where you can assign different combinations of ribbon groups to be displayed in the ribbon control. The performance first of all depends on the number of buttons in the ribbon. The skinned themes are only a bit slower than simple themes. The home page in the RibbonBar sample is slower than other pages because of the number of buttons rather than the gallery control. Besides both in ribbons and grid controls the release mode is several times faster due to lots of assertion failure checks in the debug mode.

Of course all the test were done with a release version : built on our computer 2.81, 2.82 and today 2.83. All behave the same : when hovering the mouse above the icons there is a huge delay before they get refreshed, when they doso..... the same when you change from one tab to the other, all this with a very high CPU charge... Reading through the forum we realised that we are not the only one suffering from this issue. We would like to know if this major flaw is about to be actively investigated please, we can’t rely on a non consistent behavior from one machine (fairly new machine) to the other from our clients. Again after investigations we have found that other tech, and the new visual studio feature pack behave with reasonable performance with no lags at all across our different machines, on a close GUI ribbon configuration software.

A screenshot is being sent directly to support@prof-uis.com

Thank you

First of all, Prof-UIS uses very heavy assertions in the debug mode. So, you should keep in mind that any performance issues you have in the debug version may be entirely absent in the release one.

Could you post a screen shot of the ribbon bar in the partially collapsed state when the problem is not notable?