Bug 553787 - Default to disable Redraw in AbstractTreeViewer#expandToLevel and expandAll
Summary: Default to disable Redraw in AbstractTreeViewer#expandToLevel and expandAll
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.14   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 4.15 M1   Edit
Assignee: Lars Vogel CLA
QA Contact:
URL:
Whiteboard:
Keywords: noteworthy, performance
Depends on:
Blocks: 553533
  Show dependency tree
 
Reported: 2019-12-04 18:10 EST by Lars Vogel CLA
Modified: 2019-12-12 09:03 EST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lars Vogel CLA 2019-12-04 18:10:52 EST
We have many bugs in which the tree expand was slow before redrawn was not enabled. See Bug 522335 or Bug 543737.

I suggest to change the default to redraw false, if the user does not specify a value.
Comment 1 Eclipse Genie CLA 2019-12-04 18:14:54 EST
New Gerrit change created: https://git.eclipse.org/r/153857
Comment 2 Lars Vogel CLA 2019-12-04 18:16:09 EST
Noticed this while looking at Pauls change in https://git.eclipse.org/r/#/c/153853/. 

Any concerns here?
Comment 3 Karsten Thoms CLA 2019-12-09 07:12:28 EST
How shall we identify clients that would like to have redrawing while expanding a tree? I'm not sure which are those use cases. In many cases the user would like to have a faster result. But how this behaves, for example, in the project explorer?
Some unwanted behavorial changes might be detected during a release iteration when this gets enabled early. I assume in most cases disabling the redraw while expand/collapse should be better.
Comment 4 Lars Vogel CLA 2019-12-09 08:05:09 EST
(In reply to Karsten Thoms from comment #3)
> How shall we identify clients that would like to have redrawing while
> expanding a tree? I'm not sure which are those use cases. In many cases the
> user would like to have a faster result. But how this behaves, for example,
> in the project explorer?
> Some unwanted behavorial changes might be detected during a release
> iteration when this gets enabled early. I assume in most cases disabling the
> redraw while expand/collapse should be better.

Definitely not something for 4.14 but for 4.15. I hope nobody relies on slow drawing operation, if someone does we can reconsider.
Comment 5 Lars Vogel CLA 2019-12-09 08:09:32 EST
(In reply to Karsten Thoms from comment #3)
> How shall we identify clients that would like to have redrawing while
> expanding a tree? I'm not sure which are those use cases. In many cases the
> user would like to have a faster result. But how this behaves, for example,
> in the project explorer?
> Some unwanted behavorial changes might be detected during a release
> iteration when this gets enabled early. I assume in most cases disabling the
> redraw while expand/collapse should be better.

It might also fix multiple issues, see for example Bug 442621 which will be fixed by a turned of return in collapse.
Comment 6 Karsten Thoms CLA 2019-12-09 08:33:33 EST
You asked for concerns, and this came to my mind ;) We should give it a try for early 4.15.
Comment 7 Lars Vogel CLA 2019-12-09 08:35:04 EST
(In reply to Karsten Thoms from comment #6)
> You asked for concerns, and this came to my mind ;) We should give it a try
> for early 4.15.

Indeed, I did. Thanks. :-)