Enabling & disabling of controls in HL is slow

[gkronber]

There is a noticeable delay when controls in HL are enabled / disabled (for instance when an algorithm is started, or when a problem instance is loaded).

The delay gets noticeably longer if more nested controls are displayed when they are disabled / enabled.

For instance when I load a new problem instance for a symbolic regression problem when the ProblemData parameter is selected, the time it takes to disable and enable all controls is much longer than the time for loading the problem itself.

[gkronber]

I made a quick test where I counted the number of calls of OnPaint HeuristicLab.MainForm.WindowsForms.View` and found that

• OnPaint of the ParameterListView of the Problem is called more than 2000 times when the problem instance is changed (for the GP - SymReg sample with ProblemData parameter selected).
• OnPaint of the ParameterListView of the Algorithm is called more than 80 times when the algorithm is started & paused.

[gkronber]

I tested old versions of HL and it seems the problem became apparent in release 3.3.9 while there is almost no delay in 3.3.8.

[gkronber]

3.3.9 introduced the ProgressBar when loading a problem instance (MainForm.AddOperationProgressToView and MainForm.AddOperationProgressToContent). When these methods are disabled the problem is resolved.

[gkronber]

r16501: added SuspendRepaint and ResumeRepaint calls in ProgressView before and after Control.Enabled = ...

(and removed unused code)

This massively improves the lag for problem instance loading.

However, the issue of many calls of OnPaint remains (in reduced form). For instance just opening the GA - TSP sample leads to

• 200 OnPaint calls for TravelingSalesmanProblemView and 214 OnPaint calls for the corresponding ViewHost.
• ~80 OnPaint calls for ParameterCollectionView (problem parameters)
• 1 OnPaint call for EngineAlgorithmView

Minimize -> Maximize causes

• ~50 OnPaint calls for TravelingSalesmanProblemView
• 1 OnPaint call for EngineAlgorithmView

Resize (from maximized to window) causes:

• ~ 150 OnPaint calls for TravelingSalesmanProblemView

Start and Pause of the sample causes:

~ 50 OnPaint calls for TravelingSalesmanProblemView

Starting the GA - TSP Samples again causes around 20 OnPaintCalls for EngineAlgorithmView.

[gkronber]

Observation: the number of OnPaint and OnPaintBackground calls can be reduced to a minimum by removing the TabControl in AlgorithmView (only showing the ViewHost for the problem).

In further experiments, I found that the excessive OnPaint calls are prevented if we set tabPage.BackColor = System.Drawing.Color.White; instead of currently Transparent. This also sets tabPage.UseVisualStyleBackColor = false; (from true).

r16502:16503: prevent excessive OnPaint calls by setting the BackColor in AlgorithmView tabPages. This improves redraw performance.

Even after r16502:16503 the number of OnPaintBackground calls of Views is still ~5 times larger than the OnPaint calls.

The OperatorGraphView also still receives many calls of OnPaint. (see r16505)

[gkronber]

The view for TSP problem contains another TabControl and consequently we still observe many OnPaint calls for the ParameterListView in this case. (resolved in r16504 below)

[gkronber]

r16504: set background color of tabPages to reduce excessive redraws for RunCollectionView, SingleObjectiveTestFunctionSolutionView, PathTSPTourView and TravelingSalesmanProblemView

[gkronber]

r16505: set background color of tabPages to reduce excessive redraws for AlgorithmOperatorView and EngineAlgorithmView (missed operatorGraphTabPage)

[gkronber]

What still remains is the flickering which is visible for the layout of groupboxes when the full window is resized.

[gkronber]

I made a small test application to study the problems with slow repainting on resize and identified that the SplitContainer as a root cause for problems (ItemCollectionView).

Counters are (OnPaint, OnPaintBackground, OnLayout, OnResize).

When the outermost splitter is moved all inner containers are resized (once). However, each resize causes 4 additional paint-background calls in all inner controls.

Notably, the outermost SplitContainer also receives 30 OnResize calls even though it is not resized at all. These events might be caused by minimizing the window.

[gkronber]

There are at least two different causes for the excessive calls of OnPaintBackground

• Controls beneath a TabPage are excessively repainted when the TabControl is resized.
  • Reproduce:
    1. Open HL in non-maximized window
    2. Open GA - TSP sample
    3. Select Selector-Parameter and its Windowing-Parameter
    4. Resize HL window -> all controls in the problemTab are redrawn excessively EngineAlgorithmView-Events.png​
    5. Open GA - TSP sample in a new window
    6. Switch to ParameterizedNamedItemView (for algorithm)
    7. Select Selector-Parameter and its Windowing-Parameter
    8. Resize HL window -> much smoother resizing. ParameterizedNamedItemView-Events.png​
• Controls in the right panel of a SplitControl are excessively repainted when the splitter is moved.
  • Reproduce:
    1. Create an ItemCollection<IItem> and add an ItemCollection (several times)
    2. Open the view and select all contained items
    3. Change the slider of the out-most splitcontainer -> All inner controls are repainted whereby the number of repaint calls is increased in each nesting level. BeforeMovingSplitter.png​ AfterMovingSplitter.png​

Counters are: (Paint Changed SuspendRepaint ReadonlyChanged set_Readonly Enabled PaintBackground Layout Resize)

[gkronber]

r16506: set BackColor of almost all TabPages in HL

[gkronber]

The main issue of this ticket has been resolved (slow redrawing for enable/disable especially when changing problem instances). Please review.

The solution for problem instance loading is SuspendRepaint/ResumeRepaint in ProgressView (r16501)

Generally Enable/Disable redrawing is improved by setting the BackColor of TabPages (r16502:16506)

Work on the remaining issues (resize with TabControls and SplitContainers) should be continued later in separate tickets.

[abeham]

I tested the changes. The UI performance has improved dramatically. Good work!

[gkronber]

Thanks Andreas, please let me know if you observe any redraw glitches.

[gkronber]

Reviewed r16501:16506 together with jkarder.

[gkronber]

#2845 needs to be merged first.

[mkommend]

r17069: Merged 16501-16506 into stable.