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)
Change History (27)
comment:1 Changed 6 years ago by gkronber
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.
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)
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. (resolved in r16504 below)
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)
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.
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:
- Open HL in non-maximized window
- Open GA - TSP sample
- Select Selector-Parameter and its Windowing-Parameter
- Resize HL window -> all controls in the problemTab are redrawn excessively EngineAlgorithmView-Events.png
- Open GA - TSP sample in a new window
- Switch to ParameterizedNamedItemView (for algorithm)
- Select Selector-Parameter and its Windowing-Parameter
- Resize HL window -> much smoother resizing. ParameterizedNamedItemView-Events.png
- Reproduce:
- Controls in the right panel of a SplitControl are excessively repainted when the splitter is moved.
- Reproduce:
- Create an ItemCollection<IItem> and add an ItemCollection (several times)
- Open the view and select all contained items
- 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
- Reproduce:
Counters are: (Paint Changed SuspendRepaint ReadonlyChanged set_Readonly Enabled PaintBackground Layout Resize)
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
I made a quick test where I counted the number of calls of OnPaint HeuristicLab.MainForm.WindowsForms.View` and found that