Forum

In our application, we need to reduce the CPU usage as much as possible.

The default settings for ProfUIs menus, toolbars, and CExtControlBars use an unacceptably high amount of CPU power.

In our application, we need to have 80%-90% of the CPU free for data processing at all times. Brief interruptions of less than one second are tolerable, but sustained interruptions of several seconds are not tolerable.

This may mean that we simply can’t use Prof-UIs for this application, but it would save us a lot of development time if we could still use the CExtControlBar class to manage the application’s dockable control bars.

Our tests were done using a PC with a single core, Intel Pentium 4, 3.2 GHz processor.

Things that currently use too much CPU power are:

moving the mouse over a column of menu items in a CExtMenuControlBar uses up to 50% CPU - this can be fixed by using a CMenu instead of the ProfUIs menu.

moving the mouse over a row of toolbar items in a CExtToolControlBar uses up to 50% CPU - this can be fixed by using a CToolbar instead of the ProfUIs toolbar.

moving the mouse over a group of CExtButtons or CExtRadioButton uses up to 50% CPU - this can be fixed by using a CButton instead of the ProfUIs buttons.

dragging an undocked CExtControlBar to a new location uses up to 100% CPU - this can be fixed by using the Office 2000 theme, which doesn’t show the window contents while dragging

resizing a CExtControlBar uses up to 100% CPU - we haven’t found a way to fix this yet, but there should be a simple way to disable showing the window’s contents while resizing

At first we thought that the CPU used by moving the mouse over buttons and menu items was caused by the the fade effects, but when we turned the fade effects off, by selecting the Office 2000 theme, the CPU usage was still unacceptably high.

Is there anything else we can do to reduce the CPU usage of the ProfUIs controls, or will we need to stop using the ProfUIs controls for this application?

The tests were done in Release mode, not in Debug mode.

I made the changes that you mentioned, but the CPU usage is still the same as in the previous test. However, I noticed a couple more details:

moving the mouse over a column of menu items in a CExtMenuControlBar uses up to 50% CPU if these menu items have 24-bit images associated with them, but less than 10% CPU is used if there are no images, or if the images are only 8-bit. The CPU usage is the same no matter which UI theme is selected.

moving the mouse over a row of toolbar items in a CExtToolControlBar uses up to 50% CPU in any theme other than the Office 2000 theme. If the Office 2000 theme is loaded when the program starts, then the buttons are not updated when the mouse is moved over them, and no extra CPU is used. If another UI theme is selected, and you switch back to the Office 2000 theme, then the buttons will be updated when you move the mouse over them, which can use up to 50% CPU.

moving the mouse over a group of CExtButtons or CExtRadioButton uses up to 50% CPU in any theme other than the Office 2000 theme, but this does not use any CPU in the Office 2000 theme.

dragging an undocked CExtControlBar to a new location uses up to 100% CPU - this can be fixed by using the Office 2000 theme, which doesnaˆ™t show the window contents while dragging, or by using __RESIZABLE_DOCKING_TYPE_STUDIO_2003

resizing a CExtControlBar uses up to 100% CPU - we havenaˆ™t found a way to fix this yet, but there should be a simple way to disable showing the windowaˆ™s contents while resizing



Unfortunately, the changes that you suggested don’t fix the most important issue - the CPU used by resizing a CExtControlBar. When the bar is docked, the window is not updated as the user moves the mouse while resizing the dialog, and so no extra CPU is used. When the bar is not docked, we still haven’t found a way to prevent the window from being constantly updated as the user moves the mouse while resizing the window. This can easily use up to 100% CPU.

First of all, Prof-UIS uses 32-bit bitmaps with alpha channel on any Windows OS independently of the source image/icon format. So this cannot be the source of any performance issues. We have checked mouse hover over toolbar/menu bar buttons and menu items both in MS Outlook 2007 and debug version of Prof-UIS samples on Core 2 Duo 1.8 MHz CPU and NVidia 7600 Go graphics adapter and the result was the same 25-32% of CPU usage. The resizable control bar drag-and-dropping using Visual Studio 2005 like dock markers eats up to 35% of CPU on the same machine. Resizing the floating tabbed group was the slower case which eat up to 40% of CPU. In our point of view, these results are acceptable. The results can be slower if the command updating methods for toolbar buttons and menu items are using some heavy code. The results can be even more slower, if application uses heavy code while handling its idle time. In any case, the important operations in your application can be done in the standalone thread which have higher priority.

First of all, please check performance of the Release version because we are using heavy assertion checkings everywhere in the Debug version. Secondly, to decrease the CPU usage, please do the following:

1) Turn off menu animations and expanding:

      CExtPopupMenuWnd::g_DefAnimationType = CExtPopupMenuWnd::__AT_NONE;
      CExtPopupMenuWnd::g_bMenuExpanding = false;
      CExtPopupMenuWnd::g_bMenuExpandAnimation = false;
      CExtPopupMenuWnd::g_bMenuHighlightRarely = false;

2) Turn off menu shadows:

      CExtPopupMenuWnd::g_bMenuWithShadows = false;

3) Turn on a simplified drag-and-drop algorithm for resizable control bars independently of the currently installed theme:

      CExtControlBar::g_eResizablePanelDockingType = CExtControlBar::__RESIZABLE_DOCKING_TYPE_STUDIO_2003;

4) Optionally, turn off the non-client area skinning, i.e. don’t use the CExtNCW template class.