Free cookie consent management tool by TermsFeed Policy Generator

Opened 8 years ago

Last modified 6 years ago

#2638 new defect

Redraws slow down UI in Windows 10

Reported by: abeham Owned by:
Priority: high Milestone: HeuristicLab 4.0
Component: MainForm.WindowsForms Version: 3.3.13
Keywords: Cc:

Description

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.

Attachments (1)

SuspendRepaintRegion.patch (9.0 KB) - added by pfleck 7 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 8 years ago by gkronber

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

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

comment:2 Changed 7 years ago by gkronber

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.

comment:3 Changed 7 years ago by abeham

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.

comment:4 Changed 7 years ago by gkronber

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.

comment:5 Changed 7 years ago by gkronber

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)

comment:6 Changed 7 years ago by abeham

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.

comment:7 Changed 7 years ago by pfleck

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.

Last edited 7 years ago by pfleck (previous) (diff)

comment:8 Changed 7 years ago by gkronber

r14553: reverse merged r14533 because of the reasons given above

Changed 7 years ago by pfleck

comment:9 Changed 7 years ago by pfleck

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).

comment:10 Changed 7 years ago by abeham

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

comment:11 Changed 6 years ago by gkronber

  • Milestone changed from HeuristicLab 3.3.x Backlog to HeuristicLab 4.0
  • Priority changed from medium to high

Can we please consider this for HL 4.0?

Note: See TracTickets for help on using tickets.