Free cookie consent management tool by TermsFeed Policy Generator

Opened 6 years ago

Closed 5 years ago

#2978 closed defect (done)

Enabling & disabling of controls in HL is slow

Reported by: gkronber Owned by: gkronber
Priority: medium Milestone: HeuristicLab 3.3.16
Component: Optimization.Views Version: trunk
Keywords: merged 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 6 years ago.
EngineAlgorithmView-Events.png (53.1 KB) - added by gkronber 6 years ago.
ParameterizedNamedItemView-Events.png (50.0 KB) - added by gkronber 6 years ago.
BeforeMovingSplitter.png (50.5 KB) - added by gkronber 6 years ago.
AfterMovingSplitter.png (55.5 KB) - added by gkronber 6 years ago.
CountViewEvents.patch (5.3 KB) - added by gkronber 6 years ago.

Download all attachments as: .zip

Change History (27)

comment:1 Changed 6 years 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 6 years 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 6 years 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 6 years ago by gkronber (previous) (diff)

comment:4 Changed 6 years ago by gkronber

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

comment:5 Changed 6 years 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 6 years 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 6 years ago by gkronber (previous) (diff)

comment:7 Changed 6 years 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.

Version 0, edited 6 years ago by gkronber (next)

comment:8 Changed 6 years ago by gkronber

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

comment:9 Changed 6 years ago by gkronber

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

Last edited 6 years ago by gkronber (previous) (diff)

comment:10 Changed 6 years 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 6 years 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 6 years ago by gkronber (previous) (diff)

Changed 6 years ago by gkronber

comment:12 Changed 6 years 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 6 years ago by gkronber (previous) (diff)

Changed 6 years ago by gkronber

Changed 6 years ago by gkronber

Changed 6 years ago by gkronber

Changed 6 years ago by gkronber

comment:13 Changed 6 years ago by gkronber

r16506: set BackColor of almost all TabPages in HL

Changed 6 years ago by gkronber

comment:14 Changed 6 years 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 6 years ago by abeham

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

comment:16 Changed 6 years ago by gkronber

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

comment:17 Changed 6 years ago by gkronber

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

Reviewed r16501:16506 together with jkarder.

comment:18 Changed 6 years ago by gkronber

#2845 needs to be merged first.

comment:19 Changed 6 years ago by abeham

  • Keywords depends-2845 added

comment:20 Changed 5 years ago by mkommend

  • Keywords merged added; depends-2845 removed

r17069: Merged 16501-16506 into stable.

comment:21 Changed 5 years ago by abeham

  • Resolution set to done
  • Status changed from readytorelease to closed
Note: See TracTickets for help on using tickets.