Community
Participate
Working Groups
Mylar uses a lightweight to indicate interest level for any structured viewer (e.g. the most interesting java elements are bold in the Package Explorer). The problem is that when a refresh is requested (e.g. markers change), the elements become unbolded, then bolded again when they're decorated. This is additionally aggrevated by the fact that the pause while they blink can be well over a second because the decoration job priority is so low. A more severe version of this problem shows up when a downstream plug-in (Visual Source Safe is the only one we know of) calls overly frequent refresh/decoration on the Package Explorer. The bold/unbold blinking can be continuous during check-outs and background refreshes. This problem is not Mylar-specific, but should manifest for anyone who uses bold font in a lightweight decorator. Is there a way that the font, text, and image from the last decoration could be preserved until the decoration happens and not disappear when the refresh happens? It seems that this would give behavior that's consistent with a regular decorator and be safe to downstream plug-ins causing this sort of blinking.
A few details on the configuration that causes this bug to manifest itself: Eclipse 3.2M5a, Mylar 0.4.10, and VSS plugin 1.6.1 (http://sourceforge.net/projects/vssplugin/) While the blinking is occuring, the Eclipse status bar at the lower right flashes the text "Updating Check-Out View...". If I close the "VSS Checked Out Files" view, the blinking stops and does not seem to reoccur. Disabling VSS label decorators has no effect on the blinking. So it appears that the problem is with that specific view causing excessive refresh requests. See Mylar bug 104783 for more details.
Related to bug 51168. We plan to investigate this in 3.3.
I have come up with a patch that fixes the flashing. Tod, we can discuss whether it looks safe enough to include in 3.2 on Monday.
Created attachment 38555 [details] Here's the patch
As I suspected, the patch causes problems elsewhere so it isn't suitable for release. There are actually two parts to it. One is to correct a problem with the text decorators being removed and reapplied. The patch is to the DecoratorManager and could probably be safely applied. The second is to StructuredViewer and it is this change that has undesirable side effects. I'll see if I can come up with womething else now that I understand the code a bit better.
Created attachment 38577 [details] Here's a better patch This patch addresses the issue with the first. Basically, it avoids setting the font and color if there are pending decoration calculations. If we weren;t past the API freeze I would have introduced a couple of API methods but since we are, I made them package private.
I have released the fix that prevents the color and font flashing.
Excellent! In retrospect I'm glad the bug was there because it forced me to minimze viewer refresh. Is there anything you guys use to ensure to excessive refresh does not creep in, or is that just something that comes from performance tests like those for the Package Explorer?
In the decorators we avoid duplicate requests for the same object but if an update has happened we clear this cache. If you are refreshing after we send the update you won't get the benefit of this.
My favorite tool for finding low level repaint problems (on the Mac) is the "Flash screen updates" mode in Quartz Debug. It paints a yellow rectangle outlining each area, just before it is redrawn. Similar tools must exist for other platforms.
Verified in 20060425
As far as I can tell the decoration blinking problem is still around for image overlays, right? This isn't that bad in the Package Explorer, where the decorations overlap with the icons. But in Mylyn's Task List we have some decorations that are to the left of the icons (for priority), and the blinking is quite noticeable due to the low priority of the decoration job. Is a parallel solution possible for images (e.g. retain the last image decorations until the decoration update is complete)? Should I file a new bug? Also, a related question, and possibly another bug, is whether the decoration job should have higher priority. As a UI guy, I find it more important that the tool is showing the right information (e.g., error decoration goes away in Package Explorer) than if the right bytecodes have been dumped to disk already (e.g., I won't hit F11 until that decoration goes away anyway). But I realize that some decorations really are low priority and that this might be too big a change. The problem is that combined with this bug, the delay can be multi-second long with other higher priority jobs running.
Complementing what Mik said, if you open "open resource" dialog (Ctrl+Shift+R), type something like "plugin.xml", you will see the CVS overlay being erased and repainted after ~1 second, as you click on the resources, or move the cursor with arrow keys. This seem unnecessary, no?
I think you might be seeing different issues. if we get a request for an update we do it so you may have found a scenario that is requesting updates unneccessarily. If so please log a new bug with the scenario you are seeing. The vast majority of these issues are an overly aggressive view asking to update the system too often.
(In reply to comment #13) > Complementing what Mik said, if you open "open resource" dialog (Ctrl+Shift+R), That's bug 175507.
So, it seems that this was partially fixed since as mentioned in Comment #12, the decoration blinking problem is still around for image overlays in 3.4. So, is there another bug for the blinking problem and this one is only to fix the pending decoration calculations?
