Community
Participate
Working Groups
Created attachment 279956 [details] Missing line numbers See attached screenshot. Some line numbers are not drawn when scrolling and "Show Revision information" is enabled. This is a regression from recent line ruler painting optimization in bug 366471. https://git.eclipse.org/r/#/c/149547/ I definitely tested the quick diff part but apparently forgot the "Show Revision information" variant. Thomas please take a look. PS: I made a new bug since the other is very long and this title easier to find.
I *had* tested that, but not with the latest patch set. Damn. The LineNumberChangeRulerColumn paints way beyond the line range given. So this is caused by the final "optimization" drawing directly into the buffer in the non-scaled case. So back one step and always paint into a new image, then only copy the wanted image parts.
I'm on I20190919-1800 / Linux, can'r reproduce. What are the steps?
Enable "Show Revision information" and line numbers as seen in screenshot (exact configuration shouldn't matter) and scroll editor. The revision information blocks should be at least larger than 2 lines and you must not place or move the mouse onto the ruler.
(In reply to Thomas Wolf from comment #1) > So this is caused by the final "optimization" drawing directly into the > buffer in the non-scaled case. Too bad. But I assume you could keep it this way for the dy == 0 case where the whole canvas is drawn anyway.
(In reply to Paul Pazderski from comment #3) > Enable "Show Revision information" and line numbers as seen in screenshot > (exact configuration shouldn't matter) and scroll editor. The revision > information blocks should be at least larger than 2 lines and you must not > place or move the mouse onto the ruler. OK, I see it sometimes now, the "right scrolling" with the mouse is the key.
New Gerrit change created: https://git.eclipse.org/r/149918
Gerrit change https://git.eclipse.org/r/149918 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=d9ffc72f9cff1ea0ae332ba82e4d59f1ef847624
BTW: the Mac-retina specific work-around doesn't seem to be needed anymore? See bug 516293, and the meanwhile fixed bug bug 489451.
Still broken, I'm on I20190923-1800 / GTK3. I see line numbers not painted for some lines (trying to create a screenshot paints them). I was working on eclipse.platform.resources/tests/org.eclipse.core.tests.resources/src/org/eclipse/core/tests/internal/builders/BuilderTest.java with JUnit / breakpoints and while navigating from failing test to the line / toggling breakpoints I've noticed that in few cases single line numbers were not there. Jump to testBuildClean() via Outline view and scroll down with the mouse.
(In reply to Andrey Loskutov from comment #9) > Still broken, I'm on I20190923-1800 / GTK3. > > I see line numbers not painted for some lines (trying to create a screenshot > paints them). > > I was working on > eclipse.platform.resources/tests/org.eclipse.core.tests.resources/src/org/ > eclipse/core/tests/internal/builders/BuilderTest.java > > with JUnit / breakpoints and while navigating from failing test to the line > / toggling breakpoints I've noticed that in few cases single line numbers > were not there. > > Jump to testBuildClean() via Outline view and scroll down with the mouse. Can reproduce on CentOS 7/GTK3/X11 (Gnome, Adwaita) *only with static scrollbars*. Doesn't occur with the default Gnome overlay scrollbars. Vertical pixel coordinates are off between the rectangle copied in doubleBufferPaint() and where doPaint() paints the lines. Setting the cursor on the bottom line visible and hitting arrow-down once reproduces the problem reliably for me (with static scrollbars on). Coordinate difference depends on font size and is about two lines, so doPaint paints the correct two lines, but above the area that is then copied. No idea why this happens. If I can't figure out what's going on, I'll disable this for GTK tomorrow.
(In reply to Thomas Wolf from comment #10) > Can reproduce on CentOS 7/GTK3/X11 (Gnome, Adwaita) *only with static > scrollbars*. Doesn't occur with the default Gnome overlay scrollbars. Right, overlay scrollbars are off for me, because they cause permanent redraw events (x20 more) and are bad if using Eclipse over slow ssh or vnc connection. Since overlay scrollbars cause extra redraws after scrolling, we don't see the bug if they are enabled.
No such problem on Mac, with either static or dynamic scrollbars.
I have the feeling that this might be related to bug 519728 comment 18. I sometimes see line numbers being painted next to the static horizontal scrollbar, and sometimes not. When not, scrolling up one line leads to missing line numbers on the last two lines.
New Gerrit change created: https://git.eclipse.org/r/150115
(In reply to Eclipse Genie from comment #14) > New Gerrit change created: https://git.eclipse.org/r/150115 (In reply to Thomas Wolf from comment #13) > I sometimes see line numbers being painted next to the static horizontal > scrollbar, and sometimes not. ...and error markers, too. So... sometimes JFaceTextUtil.getVisibleModelLines() returns as last line the one above the static scrollbar (case 1), and sometimes it returns a line that isn't visible at all because it's hidden behind the horizontal scrollbar (case 2). Seems to occur when the font size is such that the line height is larger than the height of that scrollbar. The basic assumption that the height of the ruler canvas was always equal to the height of the visible text area in the text viewer seems not to hold (at least on GTK); the ruler canvas can be larger. On Mac, this assumption holds; with static scrollbars the ruler canvas stops at the top of the horizontal scrollbar. The above change corrects LineNumberRulerColumn for the case that the bottom pixel of the reported bottom line is < the height of the canvas (that's case 1). Verified on OS X and GTK with static and dynamic scrollbars and found no problems. @Andrey, can you confirm, or do you still see rendering problems with this change? And could someone test this on Windows, please?
(In reply to Thomas Wolf from comment #15) > And could someone test this on Windows, please? Tested. Everything seems fine.
(In reply to Paul Pazderski from comment #16) > (In reply to Thomas Wolf from comment #15) > > And could someone test this on Windows, please? > > Tested. Everything seems fine. Thanks, Paul!
Created attachment 280025 [details] smaller issue left after patch https://git.eclipse.org/r/150115 Thanks Thomas, looks better now, I've commented on the patch, see attached screenshot
(In reply to Andrey Loskutov from comment #18) > Created attachment 280025 [details] > smaller issue left after patch https://git.eclipse.org/r/150115 > > Thanks Thomas, looks better now, I've commented on the patch, see attached > screenshot I don't have that on CentOS7/GTK/X11/Gnome/Adwaita. But my static scrollbars look completely differently. Do you get those when scrolling up or down? Or after a down-up-down? And what theme is that? If not Adwaita: do you also get that with Adwaita? If I can't reproduce this one we're not only into "SWT platform differences" territory but also deep in "Linux UI theme differences" area, where I definitely can't do much.
(In reply to Thomas Wolf from comment #19) > I don't have that on CentOS7/GTK/X11/Gnome/Adwaita. But my static scrollbars > look completely differently. Yes, I'm using https://github.com/iloveeclipse/clearlooks-phenix > Do you get those when scrolling up or down? Scrolling up with mouse wheel. Scrolling down works fine. > And what theme is that? If not Adwaita: do you also > get that with Adwaita? Same with Adwaita (except that scrollbar is tiny and so the damaged area is smaller).
OK, managed to reproduce it. (In reply to Thomas Wolf from comment #15) > sometimes JFaceTextUtil.getVisibleModelLines() returns as last line the > one above the static scrollbar (case 1) The "sometimes" was a problem. If we had this case and cleared the bottom bit, and then the next case when scrolling down was not case 1, the code even copied the cleared part up when scrolling down. And the bits shown in your screenshot come from a similar problem with scrolling up, which would not copy enough down and thus leave garbage in that little bit. For scrolling up, we can always use the ruler's canvas height. There's a minor-minor-minor difference to the old behavior in that one can see partial line numbers next to the scrollbar (bottom beyond the viewer) when scrolling up. I consider that OK; in fact, it's symmetric to the top line numbers, which also can be shown with their tops cut off. I kind of start hating this :-/ The code was so simple originally, and now it's riddled with crazy special cases just because that canvas is sized differently on GTK. :-( At least performance-wise it's still quite a bit faster on Mac compared to before I started fiddling with this. @Andrey: Hope you don't find any more problems now.
Gerrit change https://git.eclipse.org/r/150115 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=df1e7b42cac6edfefe6e878270760e0094ca6341
