Opened 2 months ago

Last modified 2 months ago

#2978 reviewing defect

Enabling & disabling of controls in HL is slow

Reported by: gkronber Owned by: swagner
Priority: medium Milestone: HeuristicLab 3.3.16
Component: Optimization.Views Version: trunk
Keywords: Cc:

Description

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.

Attachments (6)

splitcontainers.png (14.4 KB) - added by gkronber 2 months ago.
EngineAlgorithmView-Events.png (53.1 KB) - added by gkronber 2 months ago.
ParameterizedNamedItemView-Events.png (50.0 KB) - added by gkronber 2 months ago.
BeforeMovingSplitter.png (50.5 KB) - added by gkronber 2 months ago.
AfterMovingSplitter.png (55.5 KB) - added by gkronber 2 months ago.
CountViewEvents.patch (5.3 KB) - added by gkronber 2 months ago.

Download all attachments as: .zip

Change History (22)

comment:1 Changed 2 months ago by 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.

comment:2 Changed 2 months ago by 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.

comment:3 Changed 2 months ago by 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.

Only AddProgressToContent seems to be relevant.

If the AddProgessToContent method is unchanged and in ProgressView the lines 116 Control.Enabled = false and 130 Control.Enabled = true are removed then the problem is resolved. These two lines seems to be the main entry points for the long-running repainting.

Last edited 2 months ago by gkronber (previous) (diff)

comment:4 Changed 2 months ago by gkronber

  • Status changed from new to accepted
  • Version set to trunk

comment:5 Changed 2 months ago by 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.

comment:6 Changed 2 months ago by 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)

Last edited 2 months ago by gkronber (previous) (diff)

comment:7 Changed 2 months ago by 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)

Last edited 2 months ago by gkronber (previous) (diff)

comment:8 Changed 2 months ago by gkronber

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

comment:9 Changed 2 months ago by gkronber

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

Last edited 2 months ago by gkronber (previous) (diff)

comment:10 Changed 2 months ago by gkronber

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

comment:11 Changed 2 months ago by 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.

Last edited 2 months ago by gkronber (previous) (diff)

Changed 2 months ago by gkronber

comment:12 Changed 2 months ago by 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)

Last edited 2 months ago by gkronber (previous) (diff)

Changed 2 months ago by gkronber

Changed 2 months ago by gkronber

Changed 2 months ago by gkronber

Changed 2 months ago by gkronber

comment:13 Changed 2 months ago by gkronber

r16506: set BackColor of almost all TabPages in HL

Changed 2 months ago by gkronber

comment:14 Changed 2 months ago by gkronber

  • Owner changed from gkronber to swagner
  • Status changed from accepted to reviewing

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.

comment:15 Changed 2 months ago by abeham

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

comment:16 Changed 2 months ago by gkronber

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

Note: See TracTickets for help on using tickets.