search

heal-research / HeuristicLab

HeuristicLab - An environment for heuristic and evolutionary optimization
https://dev.heuristiclab.com
GNU General Public License v3.0
34 stars 16 forks source link

Redraws slow down UI in Windows 10 #2638

Open HeuristicLab-Trac-Bot opened 8 years ago

HeuristicLab-Trac-Bot commented 8 years ago

Issue migrated from trac ticket # 2638

milestone: HeuristicLab 4.0 | component: MainForm.WindowsForms | priority: high

2016-07-15 13:20:09: @abeham created the issue

Ever since I upgraded from Windows 7 to 10 a lot of operations regarding the enabling and disabling of controls take significantly more time (personal impression). For example loading a benchmark problem instance in a TSP shows a lot of flickering of the controls. Operations that were not noticeable before are now quite annoying such as switching tabs or views.

For instance, I measured about 8.3s to load Nguyen F6 in a Problem that was embedded into a GA. If the problem was not embedded the time was 1.5s. For the TSP I measured 3.6s to load the kroE100 if the problem was not embedded and 5s if the problem instance was set within a GA. If the algorithm is further embedded into an experiment it looks even worse.

HeuristicLab-Trac-Bot commented 8 years ago

2016-07-15 14:36:29: @gkronber commented

Also noticed that. Loading a problem instance fires a lot of events ans it seems that the redrawing is much slower now.

HeuristicLab-Trac-Bot commented 8 years ago

2016-07-15 14:36:29: @gkronber

HeuristicLab-Trac-Bot commented 7 years ago

2016-09-21 09:45:00: @gkronber commented

It is definitely related to enabling / disabling user controls. We are using some tricks in the base class (PInvoke user32.dll). It might be related to that.

HeuristicLab-Trac-Bot commented 7 years ago

2016-09-21 10:29:45: @abeham commented

Yes, and I have no idea why this is not working anymore. I put a question on stackoverflow. Not that I expect a good answer, but at least it's documented that way.

HeuristicLab-Trac-Bot commented 7 years ago

2016-12-27 13:06:08: @gkronber commented

r14533: proposed fix for slow enable/disable operations?

I looked into this and found that calling SuspendRedraw and ResumeRedraw in View.OnEnabledChanged() fixes some of my problems. I'm not 100% sure about the implications and why this happens.

HeuristicLab-Trac-Bot commented 7 years ago

2016-12-27 13:11:06: @gkronber commented

I also observed the following issues which are probably related:

  • slow updates when changing views (e.g. open the GA - TSP problem and switch between the Evaluator and SolutionCreator)
  • flickering and very slow updates on resize operations of nested views (e.g. open GA - TSP problem and select Parameters -> Analyzer -> BestTSPSolutionAnalyzer and then resize the window)
HeuristicLab-Trac-Bot commented 7 years ago

2016-12-27 23:23:08: @abeham commented

I don't know if r14533 is really a good solution. The first control that finishes OnEnabledChanged calls Resume and thus all UI updates thereafter are not suspended anymore.

I don't know maybe introduce some counting for calls to Suspend and Resume in order to resume only on the outermost Supsend-Resume of a long call chain. Otherwise, you're resuming quite early already. But that presents its own problems.

HeuristicLab-Trac-Bot commented 7 years ago

2017-01-05 11:00:27: @NimZwei commented

I also experienced some issues and additional flickering with r14533.

As abeham noticed, ResumeRepaint may be called too early, which is the case in the Content property of the ContentView.

When setting a new Content repainting is suspended, but calling SetEnabledStateOfControls usually sets the Enabled property (e.g. the ViewHost) which resumes repaint before the actual resume at the end of the Content property.

This leads to the problem that the ActiveView in the ViewHost is not always correctly removed. For instance, in the Result tab of an algorithm, when selecting a result, then stopping/preparing the algorithm removes all the results but the details view of the last selected result is still shown.

Flickering is noticeable well when using an ItemCollectionView that displays a “slow” view in the details. For instance, a RegressionProblemData with a large dataset (e.g. Tower) with the dataset selected. Changing to a different parameter cause 3 distinct flickers.

HeuristicLab-Trac-Bot commented 7 years ago

2017-01-05 11:00:27: @NimZwei

HeuristicLab-Trac-Bot commented 7 years ago

2017-01-05 11:00:27: @NimZwei

HeuristicLab-Trac-Bot commented 7 years ago

2017-01-09 15:04:20: @gkronber commented

r14553: reverse merged r14533 because of the reasons given above

HeuristicLab-Trac-Bot commented 7 years ago

2017-02-01 12:13:56: @NimZwei uploaded file SuspendRepaintRegion.patch (9.0 KiB)

HeuristicLab-Trac-Bot commented 7 years ago

2017-02-01 12:17:39: @NimZwei commented

I tried to use using dispose-regions to avoid multiple suspend-calls and "too-early" resumes.

Maybe we want to do this anyway, but I didn't want to commit it yet, therefore i added a patch (see above).

HeuristicLab-Trac-Bot commented 7 years ago

2017-08-16 10:52:58: @abeham commented

I like pfleck's approach on SuspendRepaintRegions. However I think we must take the view nesting into accountsomehow. Otherwise the embedded view resumes again while the parent is still suspended. Maybe always suspend/resume at the top level view?

HeuristicLab-Trac-Bot commented 6 years ago

2018-02-01 17:54:35: @gkronber changed priority from medium to high

HeuristicLab-Trac-Bot commented 6 years ago

2018-02-01 17:54:35: @gkronber changed milestone from HeuristicLab 3.3.x Backlog to HeuristicLab 4.0

HeuristicLab-Trac-Bot commented 6 years ago

2018-02-01 17:54:35: @gkronber commented

Can we please consider this for HL 4.0?