Bugzilla – Full Text Bug Listing
| Summary: | [painting] Screen cheese in line number ruler when invisible Table overlaps | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Johannes Rieken <johannes_rieken> | ||||||
| Component: | SWT | Assignee: | Abhishek Kishore <abhishek.kishore> | ||||||
| Status: | RESOLVED NOT_ECLIPSE | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | abhishek.kishore, arunkumar.thondapu, daniel_megert, g.watson, igor, justin, lshanmug, markus.kell.r, mike.jackson, mrm, pkillian, shaun, Silenio_Quarti, torkildr, ts, xcoulon | ||||||
| Version: | 3.6 | ||||||||
| Target Milestone: | 4.4 | ||||||||
| Hardware: | Macintosh | ||||||||
| OS: | Mac OS X | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Johannes Rieken
Created attachment 175948 [details]
Screen Cheese
>When I scroll, the first digit sticks.
So only in the line number ruler? Or is the blank area on the right side of the picture also part of the problem?
How do you scroll (mouse wheel, ruler, keyboard)?
Can you continue to work?
Anything in the .log?
Looks like the Java editor, right? Can you reproduce in a normal text editor?
(In reply to comment #2) > >When I scroll, the first digit sticks. > So only in the line number ruler? Or is the blank area on the right side of the > picture also part of the problem? > Only the line number ruler. The right side is looking ok. > How do you scroll (mouse wheel, ruler, keyboard)? Mouse wheel > Can you continue to work? Yes, it seemed fine > Anything in the .log? No, empty. > Looks like the Java editor, right? Can you reproduce in a normal text editor? I can't even reproduce in the Java editor, but I am seeing this from time to time (very rare, though) If it happens, does it then constantly happen in that editor, or is the ruler OK when next scrolling takes place? Once the number ruler is off, it stays like this. Re-opening (all or one editor - don't remember) fixed it I'm seeing this problem also. I think I was using the scroll wheel the last time it happened. Once the line numbers get screwed up it seems to affect all editors. Closing an editor and reopening it has no effect. The only way I can fix it is to restart Eclipse. Unfortunately, we can't reproduce this, so we depend on more information from affected users to narrow this down. Can you try to interact with the ruler when this happens again? Does a click into the ruler still set the caret to the beginning of that line? Also after you scrolled around? Toggle the line folding ruler and the line number ruler and report the effects. Open a Java editor and show the Breadcrumb. Are the black arrows between the items visible? The only "special" thing I see in the ruler implementation is that we use "new GC(image)". The breadcrumb is another place where this is used, so if there's a system-wide problem with that call, the problem should also show up there. (In reply to comment #7) > Unfortunately, we can't reproduce this, so we depend on more information from > affected users to narrow this down. Can you try to interact with the ruler when > this happens again? > > Does a click into the ruler still set the caret to the beginning of that line? Yes, even though the line numbers no longer line up with the lines. If I move focus to another non-Eclipse window, then back to Eclipse, the ruler is redrawn correctly. However the problem returns as soon as I scroll a single line. > Also after you scrolled around? Yes. > > Toggle the line folding ruler and the line number ruler and report the effects. I disabled folding in Java>Editor>Folding, but no difference. When I disabled the line number ruler, I noticed that the folding -'s and +'s are also not aligned correctly when the buffer is scrolled, and some of the icons are glitched as well. It looks like the glitch is at the same location as the line number glitch. As soon as I mouse over the ruler, the folding icons are repositioned correctly, but the line numbers still stay glitched. Toggling folding and line numbers has no other effect, the problem is still present when they are re-enabled. > > Open a Java editor and show the Breadcrumb. Are the black arrows between the > items visible? The only "special" thing I see in the ruler implementation is > that we use "new GC(image)". The breadcrumb is another place where this is > used, so if there's a system-wide problem with that call, the problem should > also show up there. I right clicked and selected "Show in Breadcrumb". The ruler remains the same and the breadcrumb looks ok. Any news on this? I get it frequently enough to consider it a major problem with the OS X version of Eclipse. (In reply to comment #9) > Any news on this? I get it frequently enough to consider it a major problem > with the OS X version of Eclipse. We need a reproducible case, otherwise there's nothing we can do. Well, this seems to be an intermittent problem, or at least have no obvious way of reproducing, but nonetheless it's a bug that needs to be fixed. Can you suggest any way I can help debug this? Is there any logging or tracing I could turn on that would help> > Can you
> suggest any way I can help debug this? Is there any logging or tracing I could
> turn on that would help>
There are no debug options that would help here. The only thing is really to find out the pattern that produces the cheese or remote debug your workspace with a breakpoint in org.eclipse.jface.text.source.LineNumberRulerColumn.doPaint(GC, ILineRange).
I also have this problem with C++ editors in CDT. Both in the Helios Cocoa 64 Bit release and the Indigo RCs. The Carbon builds of Helios do not seem to have this problem. This is on OS X 10.6.8 Intel. Anyone know what the issue was under Carbon? I can usually resize the whole Eclipse window and the Line numbers will update. But as soon as I start scrolling the problem will come back. Thanks. This has been getting up my nose also, seems more than intermittent, and I think I've just found a way to reproduce this at will. 1. Open a java source file, with at least enough lines to not all be visible 2. Page up/down, scroll via mousewheel/touchpad etc and observe the ruler line numbers update correctly 3. Now open a multi-page editor, e.g. Plug-in Manifest editor (via plugin.xml or manifest.mf) 4. Select your java editor and repeat step 2 and you'll see the repaint issues/cheese 5. Close the manifest editor and the ruler now updates correctly once more I can open any number of java source files and the ruler is fine but as soon as I open a manifest editor then it's messed up. Just tried opening a pom editor and a .exsd schema editor - the java ruler is fine with these, so it's not just *any* multi-page editor... (In reply to comment #14) Thanks, that was very helpful. I can also reproduce now like this (3.7, Cocoa 32bit on 10.6): - open a long .java file, show the line number ruler - open a plugin.xml editor and go to the Dependencies tab - switch back to the Java editor (keep both editors in the same editor stack) => the ruler doesn't update any more, and it draws cheese in the area where the Dependencies page of the other editor shows the focus ring of the Required Plug-ins table. Looks like a problem in SWT when a table is not visible but overlaps the text editor ruler. Also happens on the Runtime and Extension Points tabs, but not on the Extensions tab (the former two also use a Table, whereas the latter uses a Tree). org.eclipse.jface.text.source.LineNumberRulerColumn#redraw() contains special code for the Mac, but I also see the cheese when I set IS_MAC to false here: if (IS_MAC) { fCanvas.redraw(); fCanvas.update(); } else { GC gc= new GC(fCanvas); doubleBufferPaint(gc); gc.dispose(); } Moving to SWT. *** Bug 355291 has been marked as a duplicate of this bug. *** Also present in 4.2M2. I'm seeing this in M7 also. It seems to occur any time a plugin.xml editor is open. *** Bug 381239 has been marked as a duplicate of this bug. *** Created attachment 219888 [details]
hack
This hack avoids the problem. For some reason, it happens when NSView.displayIfNeed() is called from NSView.scrollWheel(). The tree widget needs to overlap the view being updated as well.
I am not sure avoiding NSView.displayIfNeed() is a proper fix. Need to investigate more.
*** Bug 392620 has been marked as a duplicate of this bug. *** *** Bug 403184 has been marked as a duplicate of this bug. *** Abhishek, please try to work with Silenio and provide a proper fix for this bug. (In reply to Arun Thondapu from comment #23) > Abhishek, please try to work with Silenio and provide a proper fix for this > bug. I can't see the issue on Mac OS 10.9.1. Its probably a defect with the Mac OS API on 10.6. Yup, still broken with 10.8.5, but works fine with 10.9.1. (In reply to Markus Keller from comment #25) > Yup, still broken with 10.8.5, but works fine with 10.9.1. Thanks for the confirmation. Resolving it. *** Bug 320718 has been marked as a duplicate of this bug. *** |