Forum

Lately your services have become obviously subpar while the performance of Prof-Uis is lagging other equivalent packages. Despite numerous attempts on my part to notify you and to narrow down the problems by becoming a virtual beta-tester, your support practically ignored my messages regarding flickering and jitters in the functionality of your library.

Consequently, unless you define a clear and publicly verifiable path of addressing the performance problems in Prof-Uis, I find myself in the regrettable situation of not being able to renew my subscription.

Regards,

Bogdan

Thank you for your response.

My main concern is the flickering I mentioned in my previous messages: it has little to do with the number of control bars...

In a MDI application there is only one control bar docked on the right side of the frame and no child view (i.e., the background MDI client window is visible). If one widens the main frame by dragging its left side, Prof-UIS moves first the control bar to the left at the same distance it was in the initial view and only after that if repositions the control bar in its docking positions creating a visible left-right flickering. I sent you a couple of times emails with snapshots of the effect described here (use ’Performance settings’ in the ’System properties’ adjusted for ’Best performance’). Eliminating the useless movement to the left of the control bar would solve the flickering problem. This issue likely gets worse with the number of control bars but it is clearly visible even with one control bar on I7-based computers. The same thing happens with the control bars docked to the bottom of the main frame. As long as Prof-UIS takes over the way child windows are rendered, there is surely a way (albeit difficult) to solve this flickering.
I would appreciate any guidance regarding this.

Bogdan

PS
As for the jittering while hiding/showing the controlbars whenever not pinned, I guess one could fiddle with g_nAutoHideAnimationStepCount and g_nAutoHideAnimationStepTime to obtain a better behavior.

This is not introduced by Prof-UIS. This is effect of delayed non-client area recalculation. It’s present in all the Windows applications. We checked Office 2010 Word (Clipboard control bar), Visual Studio 6.0 and 2008.

But isn’t Prof-UIS controlling the rendering process for the Office-based (skinned) themes?

In any case, the window area consist of the inner client area and the outer non-client area. If you see a skinned window frame in Prof-UIS app, then the Prof-UIS measures the size of non client area and paints it. Otherwise you can see the by default measured and painted window non-client area in the DefWindowProc() function. It’s not important which procedure handles the WM_NC*** messages for measuring, painting and hit testing non-client area. It can be DefWindowProc() or CExtNCW::WindowProc(). The resized window principally cannot be immediately updated. Theoretically, it’s possible to code layered window based on per-pixel transparency (i.e. initialized via UpdateLayeredWindow() API) and code window surface as single memory bitmap. But such approach is incompatible with MFC application design.

We re-checked the flickering issue. The ProfStudio sample application displays 42 bars, which makes the ui quite heavy. We confirm ProfStudio does not show best performance. It depends on the number of control bars. Performance is better in SDI environments and, you may notice, Microsoft’s apps does not use the standard MDI. We are sorry if there were any delays with our response.