Opened 15 months ago

Last modified 2 months ago

#2638 new defect

Redraws slow down UI in Windows 10

Reported by: abeham Owned by:
Priority: medium Milestone: HeuristicLab 3.3.x Backlog
Component: MainForm.WindowsForms Version: 3.3.13
Keywords: Cc:


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 9 months ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 15 months 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 13 months ago by gkronber (previous) (diff)

comment:2 Changed 13 months 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 13 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months ago by pfleck (previous) (diff)

comment:8 Changed 9 months ago by gkronber

r14553: reverse merged r14533 because of the reasons given above

Changed 9 months ago by pfleck

comment:9 Changed 9 months 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 2 months 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?

Note: See TracTickets for help on using tickets.