Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 59037

Summary:	[Navigator] Package explorer flicker when switching/closing editors
Product:	[Eclipse Project] Platform	Reporter:	Dan Berindei <dberindei>
Component:	UI	Assignee:	Nick Edgar <n.a.edgar>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	billy.biggs, dirk_baeumer, snorthov
Version:	3.0
Target Milestone:	3.1 M7
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Dan Berindei

2004-04-19 05:02:10 EDT

If 'Link with editor' is active I see a lot of redrawing going on in the Package
Explorer view when I switch between editors (or close an open editor).

If the file opened in the second editor already appears in the Package Explorer,
it is simply selected and there is no flicker. If, however, the view has to be
scrolled to show the second file, I see a lot of redrawing before the view is
shown in the new position.

The Outline view also seems to draw a white background before drawing the
content for the active editor, but it's not nearly as annoying as the Package
Explorer (it's true that hte PAckage Explorer has much more items, though).

Comment 1 Dirk Baeumer

2004-04-19 05:39:32 EDT

The linking is implemented by calling fViewer.setSelection(newSelection, true) 
where new selection contains the element presented in the editor.

Moving to Platform/UI for comments.

Comment 2 Nick Edgar

2005-05-03 11:56:16 EDT

There was an issue with the way AbstractTreeViewer was implemented.
To reveal /A/B/C/D.java, it would:
- create children for A
- expand A
- create children for B
- expand B
- create children for C
- expand C
- select and reveal D.java

I've changed to create all parent elements before expanding them, and to do the
expansion bottom up:
- create children for A
- create children for B
- create children for C
- expand C
- expand B
- expand A
- select and reveal D.java

This should result in much less flicker and jumpiness.

Comment 3 Nick Edgar

2005-05-03 11:57:33 EDT

While tracing through this, I noticed that the tree widget repaints itself
eagerly, when disposing the dummy element or toggling expansion state, even
though events are not getting processed yet.  Steve, is this expected?

Comment 4 Nick Edgar

2005-05-03 13:06:13 EDT

Steve says that the explicit setExpanded and showItem calls should not be
necessary if the resulting items are being selected with setSelection, so I've
changed AbstractTreeViewer.setSelection to call internalExpand with
expand=false, and commented out the showItem call.
This works fine on Win2K.  Need to test on GTK and the Mac.

Comment 5 Steve Northover

2005-05-03 13:09:08 EDT

... and Motif.  BB to make sure that SWT doesn't have a bug in this area.

Comment 6 Steve Northover

2005-05-03 13:10:33 EDT

Windows paints when Windows wants to paint.  It's possible that we are forcing 
this somehow to work around a bug.  Should we investigate more?

Comment 7 Nick Edgar

2005-05-03 13:22:43 EDT

I think the changes here should reduce the amount of explicit painting done by
Windows anyway, so let's just try running with this for a while and see if it
improves things.  It should hopefully make a big improvement for Link with Editor.

Comment 8 Nick Edgar

2005-05-06 11:46:44 EDT

Billy, can you confirm that this change works OK on GTK, Mac and Motif?

Comment 9 Billy Biggs

2005-05-10 18:17:25 EDT

Looks good to me on GTK+, Motif, and Carbon on I20050510-0010.

Comment 10 Nick Edgar

2005-05-10 18:37:59 EDT

Thanks Billy.

Comment 11 Nick Edgar

2005-05-10 18:40:32 EDT

Verified in I20050509-2010 on Win2K.