Community
Participate
Working Groups
Created attachment 243334 [details] Screenshot 4.4 RC1. Already happens since at least I20140218-0800 (before Luna M6). Doesn't happen in 4.3.2. I see screen cheese in the Git Staging view trees when the view gets focus by a click on a selected file. Steps: - have a Git repo with unstaged files - select one or more unstaged files - click into another view - click a selected file in the Git Staging view => The background of the whole tree is erased and only the selected files are repainted. The border, scrollbars, and other tree items stay blank until the mouse is moved over them. We had similar issues in the platform (bug 433858), but those issues only appeared in M6 and M7.
I've made the comparison between the Package Explorer and the Navigator and the explorer intensively uses the Tree.setRedraw calls. After applying the following change to the ResourceNavigator class, used by the Navigator, the cheese is gone: protected void initListeners(final TreeViewer viewer) { viewer.addSelectionChangedListener(new ISelectionChangedListener() { public void selectionChanged(SelectionChangedEvent event) { viewer.getControl().setRedraw(false); handleSelectionChanged(event); viewer.getControl().setRedraw(true); } }); Daniel
The Git Staging view doesn't use the setRedraw method neither Daniel
(In reply to Daniel Rolka from comment #1) > I've made the comparison between the Package Explorer and the Navigator and > the explorer intensively uses the Tree.setRedraw calls. After applying the > following change to the ResourceNavigator class, used by the Navigator, the > cheese is gone: > > protected void initListeners(final TreeViewer viewer) { > viewer.addSelectionChangedListener(new ISelectionChangedListener() { > public void selectionChanged(SelectionChangedEvent event) { > viewer.getControl().setRedraw(false); > handleSelectionChanged(event); > viewer.getControl().setRedraw(true); > } > }); > > Daniel That would be wrong. setRedraw(true/fals) is expensive as it redraws the whole tree. This must only be done if bigger changes happen (to the UI), like setting the input, the comparator or when a lot of new elements are added/removed. Doing this when setting the selection is a no go.
This is deep in SWT land (Windows only) and apparently caused (according to bug 435536 comment 9) by a deliberate hack on Windows. It also appears that bug 433858 is not fixed; see bug 458015. The issue still occur in the git staging view as described by Markus in Oxygen. *** This bug has been marked as a duplicate of bug 458015 ***
