Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#887 closed defect (done)

Slow responding UI in 3.3

Reported by: abeham Owned by: swagner
Priority: highest Milestone: HeuristicLab 3.3.0
Component: Core.Views Version: 3.3
Keywords: Cc:

Description

It takes a relatively long time for e.g. a ValueParameterView hosting an OperatorView to show and become available for user input. The controls stay disabled after showing up and remain so for a noticeable period.

Attachments (1)

UI_Lag.patch (14.7 KB) - added by abeham 12 years ago.
patch against r2866 that fixes some of the UI lags

Download all attachments as: .zip

Change History (14)

comment:1 Changed 12 years ago by abeham

  • Status changed from new to assigned

One reason may be that there are a number of statements that disable GroupBoxes and Panels that contain other controls. Sometimes these statements occur before e.g. setting the Content of a ViewHost to null. The call to disable a control however cascades to all child controls and thus disables all controls in the ViewHost which are then deleted anyway.

This seems to be only one reason however.

Changed 12 years ago by abeham

patch against r2866 that fixes some of the UI lags

comment:2 Changed 12 years ago by abeham

I added a patch that fixes some of the problems with the UI. Specifically:

  • I removed several of the .Enabled = false / .Enabled = true statements. I assume it does not matter when a group box is enabled when the content is set to null.
  • The SelectedIndexChanged event of ListView fires multiple times, as it first deselects all items before selecting again. I added MouseUp and KeyUp events instead of SelectedIndexChanged that load the respective content in ItemCollectionView. This workaround was one described in the user comments of the MSDN doc.
  • NamedItemView the call to set the ReadOnly property to false has been removed in the Content == null branch. I assume that if it's not enabled anyway it doesn't matter if it's ReadOnly or not.
  • ParameterizedNamedItemView call to enable or disable the !parameterCollectionView has been removed. Id did not add anything, except maybe causing troubles with the UI updates.
  • Several changes to ViewHost have been made:
    • Throwing an ArgumentException was removed in the setter of ViewType. But in any case it fits better here than in UpdateView.
    • A check was added if the ViewType property was really changed or same to what it was before. The reason is that the forms designer creates ViewType = null statements that can be ignored when ViewType was already null (after creating a new instance of ViewHost just a few lines before)
    • The initialize method was shrunken considerably. There was some code duplication between Initialize and UpdateView (disposing the controls for example). Some of the code has moved to UpdateView.
    • In UpdateView the control is removed before disposing. This didn't make things better, but seems cleaner. Calling Dispose on a control would also remove it from its parent container.
    • The ArgumentException has been disabled. I think it's not a good idea to throw an argument exception here. But that's preference. In any case it should probably be an InvalidOperationException instead.
    • Again Enable and Visible changes of the !viewPanel have been removed

comment:3 Changed 12 years ago by swagner

  • Owner changed from abeham to swagner
  • Status changed from assigned to new

Added some of the suggested improvements in r2870. UI reaction times are significantly better now. Thanks abeham.

comment:4 Changed 12 years ago by swagner

  • Status changed from new to assigned

comment:5 Changed 12 years ago by swagner

  • Status changed from assigned to new

comment:6 Changed 12 years ago by abeham

I looked into the issue of having slow disable updates when starting an algorithm. Unfortunately, I couldn't find anything in our code. I assume that windows forms is not very effective at handling the recursive disable/enable.

There is another solution proposed here, which works, and which I have implemented in AlgorithmView to demonstrate the effect. I liked the solution of putting the code into extension methods of Control. Probably the extension method class should go into a new project such as HeuristicLab.Common.Views. For now, I wanted to keep the changes simple to review this solution.

See changeset in r3149

comment:7 Changed 12 years ago by swagner

Thanks abeham. This is a great solution.

I suggest that we move the extension methods of Control into HeuristicLab.MainForm.WindowsForms.

comment:8 Changed 12 years ago by swagner

  • Status changed from new to assigned

comment:9 Changed 12 years ago by swagner

Moved extension methods of Control from HeuristicLab.Core.Views to HeuristicLab.MainForm.WindowsForms and suspended/resumed repainting in some controls to improve UI response times in r3177.

comment:10 Changed 12 years ago by mkommend

added Suspend- and ResumeRepaint calls in ViewHost and ViewHostPanel r3720

comment:11 Changed 12 years ago by swagner

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:12 Changed 12 years ago by swagner

  • Milestone changed from Iteration 4 to Current

Milestone Iteration 4 deleted

comment:11 Changed 12 years ago by swagner

  • Milestone changed from Current to HeuristicLab 3.3.0

Milestone Current deleted

Note: See TracTickets for help on using tickets.