views:

172

answers:

4

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?

+4  A: 

I would suggest that you suspend the redrawing of the 2 panels, as long as the splitter is moving, or use a specific value, such as 50px, where you redraw again.

dwo
Right - don't allow drawing until the mouse button is released.
Chris Thornton
Well, i could return the splitter to "Pattern" mode; but then it wouldn't be in "Update" mode.
Ian Boyd
A: 

Make a test version of your form, delete all of the controls and leave yourself with just teh panels and splitter. See if performance is still sluggish.

Put some non-blocking messages (to a file, console debugger, gexperts debugger) in the resizing events. Do you get just a few, as you'd expect, or dozens?

Left panel and splitter should be aligned alLeft, and the other one alClient.

Chris Thornton
+2  A: 

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 AlignControls and only adjusting the alignment once each time the splitter moves, but it will involve quite a bit of work.

Alternatively, TSplitter has a ResizeStyle property 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.

Craig Peterson
+1 for suggesting profiling
David M
A: 

It is mostly due to repaint events of those many controls

You could try disabling background paint in your form (reduces # of paints):

procedure WMEraseBkgnd(var Message: TWMEraseBkgnd); message WM_ERASEBKGND;

...

procedure TfrmBaseMain.WMEraseBkgnd(var Message: TWMEraseBkgnd);
begin
  Message.Result := 1;
end;
André