Community
Participate
Working Groups
In org.eclipse.jface.action.ToolBarManager's update() method, setRedraw() is called on the toolbar if three or more items on the toolbar have changed: boolean useRedraw = (clean.size() - (mi.length - toRemove.size())) >= 3; The Java content outline has 5 toolbar items. Whenever the user switches between two Java editor tabs, these 5 items are replaced by 5 identical toolbar items. Using setRedraw in this case causes a flash to the background colour when I switch tabs. I am not entirely sure what to suggest here. A simple fix is to not call setRedraw(), or increase the number of toolbar items that has to change to be 6. I have not yet tested the effect of these changes on Windows.
Right now, I'm leaning toward not making any change to the tool bar code. While I can see the benefit on the Linux-GTK+ case, it is not a large benefit. In the Windows case, I think it actually gets a little bit worse. If I saw the difference on a slower machine, or if more people were noticing this problem, then I might change my mind. I'm more inclined to ask that JDT change how they use the code. They are unnecessarily adding and removing "duplicate" items (contribution items that have the same icon/behaviour). If they shared the contribution items, then this would fix this problem as well as some memory problems. I'll leave this bug open to think about again after 3.1.
Doug, could you log a new bug for JDT and indicate what would be better if they shared contribution items.
Logged as Bug 93713
While JDT Text might implement shared (retargetable) contributions items for the Java editor outline view toolbar in the future this is separate from fixing the flashing in general: unless this new paradigm (clients should use shared contribution items) is propagated and clients adopt it won't reduce the flashing in other plug-ins/products.
The flashing is a trade-off: if many items are removed, and new ones added, this will be visible to the user as a rapid animation. Using setRedraw() trades this animation for a flash to gray. If all of the toolbar items were changing, my preference would be the animation over the flash. I think that on Windows, the flash is preferred because it is very brief, while the animation is more obvious. Regardless, since in the JDT case the toolbar items aren't even changing, they're just being swapped for identical toolbar items, sharing the contribution items would avoid the issue completely.
Is there a way we can avoid the animation without using setRedraw? The toolbar should only paint went the paint event is received, not as individual items are being added/removed.
I think I have been fooled. I played around a bunch on Windows and Linux and I believe that the animation I was seeing is entirely due to the setBounds() and is still reproducable on both Linux and Windows even with the calls to setRedraw(). Switching between an ant build.xml and a Java editor shows no animation or flashing on both Windows and Linux without the calls to setRedraw().
Moving Dougs bugs
Assigning to component owner PW
*** Bug 394832 has been marked as a duplicate of this bug. ***
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/167773
+1 from project lead for RC1.
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/167773 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=9ff4e4205a6ed5e1f9405cd43f741585eb4fe9ee
