Forum

I have a window that utilizes a custom paint routine to draw network elements with connections and background pictures. The elements can be dragged around, and the movement is displayed in realtime. To optimize speed, only the needed portion of the window is redrawn. After I changed the dialog to be derived from CExtNCW<CExtResizableDialog> (previously is was derived from CExtResizableDialog), there is some serious performance issues when dragging elements around inside the window.

In which way the drag-and-drop feature is implemented in your application? Is it based on the OLE drag-and-drop or on the image list? In any case, the drag-and-drop of any item from the list view, tree view or other control should not depend on the skin. It is not good idea to implement drag-and-dropped images on the dialog background because it may have an absolutely different color schema in different skins. Please provide us with more details on these questions.

It is not based on either OLE or image list. No windows or MFC controls are used whatsoever. The OnPaint routine paints the background and the objects. When an object is moved (OnMouseMove), the necessary window portions are invalidated with InvalidateRect. It seems to me like the complete window is repainted each time when I use skins. This could explain the performance issue.

The skin is based on the stretched bitmap output which is based on the StretchBlt() and AlphaBlend() APIs. We always tried to avoid using these APIs because they are well know as not fast enough but it is not possible to avoid using them when painting the skin. This is really the top reason of why the skin cannot be so fast as non-skin themes. In any case, we will check the region clipping issues while painting as you advise us.

The skin sample has "serious" performance issue here on my computer, it take roughtly a bit less than 1 sec to change menus from "color controls" to "Input Fields" and so on, the resize of the main window is also slow.. although the office themes are nealry realtime responsive.

Thank you

Skins can be loaded in two ways: From XML files that contain references to about 300 PNG files (the PNG format uses ZIP compression) or from binary SKIN files which are ZIP-compressed on-the-fly CArchive stream containing the same information. The binary SKIN loading works faster, but it is the speed of loading about 300 PNG images and at the moment we don’t see any places for serious speed optimization. The current skin load speed is not very important if the skin is loaded at the application startup. The skin change operation should not be performed often at run time. We guess we should pay attention to freezing any windows when the skin is changed/installed/uninstalled. This will certainly make the skin change much smoother even if it takes one second long.

The resize operation is much slower when in the skin mode. We confirm that the problem exists. The skin painting is based on AlphaBlend() API on Windows 2000 or later. This API as well as StretchBlt() API is known to be slow, but we have no other alternative API for alpha blended output with stretching. The bad news is that the skin subsystem is even more slower on older Windows OS versions because we use hard-coded bitmap painting there.

In both cases, please note the ProfSkin project has only just been released.