i have a form, which you can pretend is laid out like Windows Explorer:
- panel on the left
- splitter
-
client panel
+------------+#+-----------------------+ | |#| | | |#| | | |#| | | |#| | | Left |#| Client | | |#| | | |#| | | |#| | | |#| | | |#| | +------------+#+-----------------------+ ^ | +----splitter
The the left and client area panels are each rich with controls.
The problem is that using the splitter is very sluggish. i would expect that a modern 2 GHz computer can re-display the form as fast as a human can push the mouse around. But that’s definitely not the case, and it takes about 200-300 ms before the form is fully re-adjusted.
The form has about 100 visual controls on it, no code, or custom controls.
How do i go about tracing who’s the cause of the sluggishness?
Use a profiler. Eric Grange’s Sampling Profiler is good. AutomatedQA’s AQtime is excellent.
This is more than likely due repeated resizes and repaints as the controls adjust their layouts and sizes. Lots of nesting or just lots of controls in general can cause problems. You can avoid that by overriding
AlignControlsand only adjusting the alignment once each time the splitter moves, but it will involve quite a bit of work.Alternatively, TSplitter has a
ResizeStyleproperty that controls whether the controls move immediately or a line is XOR’d over the form, and the controls only update at the end. Not as nice visually, but a lot less work.