Community
Participate
Working Groups
F1 1) Open a java editor 2) Switch to another perspective 3) Switch back Note that the action sets associated with the java editor are removed then readded. When switching editors we calculate and action set delta and do the minimum required change, we should do the same when switching perspectives.
Similar happens when closing a java editor and another java editor becomes active. This is tricky to optimize in our current WorkbenchPage framework but it may be worth a second look.
Toolbar also flashes horribly when clicking between views and editor. e.g. packages view and java editor.
The flash when switching between a view and the editor is only happening with cool bars turned on.
Flashing between views and editors is addressed in PR [Bug 16797] Extra toolbar flash when moving to/from an editor.
When switching between 2 perspective, lots of changes happen in the window (views come and go, layout change, menu change, toolbar change, shortcut bar changes, etc). It would be nice to minimize the toolbar flash, but given all the other flashing going on, it's not too critical at the moment.
Should also investigate other flashiness.
Not going to happen for M4
If I do the following: - open a new window with a resource perspective - save that perspective as Resource2 - open the Resource perspective (in the same window so now both Resource and Resource2 perspective are in the shortcut bar) - open a java file in Resource perspective - switch between perspective. Notice the toolbar stays constant, but the menu bar flashes. Need to investigate whether we can avoid the menu bar changes. Aside from that, the other flash problems seem to be taken care of.
Not much more that we can do to avoid the menu flash. Hence, we have asked SWT to provide a setRedraw() method on Menu to avoid redrawing the menu on each add/remove item - this causes flash when multiple items being added/removed.
To verify SWT changes to menubar redraw.
This looks good on Windows 2000 and GTK. There is no more menu flashing. On Motif, the menu redraw is not great but acceptable - SWT says this is a platform limitation. However, the toolbar is flashing now. This may be because of the toolbar work that Lynne has been doing (contributing actions to another action set cool item). Moving to Lynne to investigate.
Just tried an inner eclipse with the coolbar changes and I do not see any flash in the coolbar. I tried the above scenario. Is there some other scenario to try Simon?
Nick/Simon what flash are you talking about? The above scenario does not cause flash. The only flash I see is when switching between a *.java editor and a *.class file editor (i.e., give focus to each one). Is this what you are talking about? If so, this is an SWT bug.
Opened SWT bug report [Bug 32855] for flash that occurs when item removed/added to the end. SWT bug report [Bug 17994] already exists for the gripper flash that occurs when items are removed/added.
Did you try the steps in comment 8? What you see when switching between the two perspective is tool items being removed and then readded. A few weeks ago, there you did not see any changes when switching between perspective.
For comment 8, if I have an editor opened, I notice flash. This is most likely being caused by [Bug 32855]. If I have no editors opened, I see a slight flash once in awhile. CoolBarManager>>update is being called in this scenario, but it is NOT doing anything to the coolbar (i.e., no items are added/removed). So something else is causing the slight flash. When looking into this, I noticed that the code path this scenario takes causes updateActionBars to be called 3 times. If you have an editor opened it is called 5 times.
The only thing left to do here is have SWT bug 32855 fixed.
This is better based on the fix for the first problem in 32855.
