While trying to modernize the appearance of an old C++Builder / Delphi application, I enabled visual themes (visual styles) and was surprised at just how much of a performance hit themes added. For example, for our primary setup page (an 11-tab, 200-control monster dialog that we don’t want to redo right now for reasons of development time and retraining costs):
- Without themes enabled: ~0.1 sec to construct the form and its controls (as measured by QueryPerformanceCounter), ~0.9 sec from clicking the menu item to the form being shown (as measured by stopwatch). Not really noticeable to the end user.
- With themes enabled: ~0.6 sec to construct the form and its controls, ~1.5 sec from clicking the menu item to the form being shown. Very noticeable to the end user.
I get similar results on both a Windows XP desktop and a Windows 7 VM.
I realize that there are steps I could take to improve this particular case (such as lazily loading the dialog’s tabs or redesigning it completely), but is it typical for themes to add such a noticeable performance hit? Are there any easy suggestions for avoiding this performance hit?
Wow. I’m not sure I’ve ever had 200 controls on a single form. Here are a couple of suggestions.
This might be a special case where you want to create the dialog once when the application starts and display it when needed instead of creating it on demand.
I’d also look at what’s going on in the constructor or OnShow event. Are you populating any lists where BeginUpdate/EndUpdate would be an advantage?
Do you have any code in an OnResize event or similar that gets fired more than once that could wait until after the form is created and be run once?
What kind of controls are you using? If one type of control paints particularly slowly, you might be able to replace it with one that paints more quickly. This would require some testing, though.