Redraws slow down UI in Windows 10

[abeham]

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.

[gkronber]

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

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

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

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

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

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

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

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

[gkronber]

r14553: reverse merged r14533 because of the reasons given above

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

[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?

[gkronber]

Can we please consider this for HL 4.0?