Community
Participate
Working Groups
Created attachment 285541 [details] video with an example See recorded video. Looks like we've broke repainting of line number ruler somehow, I see cheese while scrolling, and the cheese stays until next scroll or resize event. I can see the problem by mouse / keyboard scrolling in an editor on a small text, bigger input with number of lines > 99 seem to be not affected.
good eclipse-SDK-I20210207-1800-linux-gtk-x86_64 bad eclipse-SDK-I20210208-1800-linux-gtk-x86_64
This looks like regression from bug 569691 / patch https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/175409. Switching SWT to commit 05888fc3f9d93910f38df725911e4c04cf5688ff (and native SWT to 5bdae9a812ab4d1c84916f3e1e83f62dc2c3adc4) fixes the broken lines. Paul, Sravan, could you please check that?
Looking on patch for bug 569691 (and seeing nothing special) I wonder if there is some bug in the JFace, especially in LineNumberRulerColumn.doubleBufferPaint(GC) that is revealed now. Thomas, Mickael - you know that ruler code - any ideas if some "caching" there could be broken on new SWT Image / Device code? I assume the offscreen painting on Image is where the bug happens.
No idea. That SWT commit does change Image, though.
Created attachment 285543 [details] Same cheese on String class (In reply to Andrey Loskutov from comment #0) > I can see the problem by mouse / keyboard scrolling > in an editor on a small text, bigger input with number of lines > 99 seem to > be not affected. I've seen that also with larger lines count. Open String class, scroll to the bottom, and scroll a bit up and down with the mouse wheel there. Cheese...
OK, it looks like a missing repaint somewhere. If I de-activate Eclipse window by clicking on the window shown next to it, cheese disappears. Steps to reproduce: Open String type Scroll to last line in file Put the cursor on first visible line Press <Key Up> to scroll editor one line up Cheese. With this steps, the same line is painted over and over again.
Sorry, I don't have a clue here. I won't be available to investigate soon, but I imagine some logging in LineNumberRulerColumn about the redrawn areas should help to identify what's wrong.
I tried on Ubuntu, but can't reproduce this problem there. Are you using RHEL/CentOS?
(In reply to Sravan Kumar Lakkimsetti from comment #8) > I tried on Ubuntu, but can't reproduce this problem there. Are you using > RHEL/CentOS? RHEL 7.4, GTK 3.22.
For me it looks like the GC.init() or GC.drawTextInPixels() or GC.drawImage() are related, may be GC must be adopted after change from gdk_window_create_similar_surface to cairo_image_surface_create. The code path is LineNumberRulerColumn.doubleBufferPaint(GC) LineNumberRulerColumn.doPaint(GC, ILineRange) LineNumberRulerColumn.paintLine(int, int, int, GC, Display) and "special" on scrolling up code in LineNumberRulerColumn.doubleBufferPaint() is that only in this case we create a *second* offscreen image, see lines along: // Some rulers may paint outside the line region. Let them paint in a new image, // then copy the wanted bits. So I believe that that GC.drawTextInPixels() or GC.drawImage() on the second image isn't working properly after gdk_window_create_similar_surface to cairo_image_surface_create change. I will push a patch for LineNumberRulerColumn with a "fix" that avoids using a second offscreen image, to demonstrate where the problem is, but the real bug is somewhere in SWT.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/176223
I believe GC.copyAreaInPixels(int, int, int, int, int, int, boolean) called from https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/176223/1/org.eclipse.jface.text/src/org/eclipse/jface/text/source/LineNumberRulerColumn.java#727 isn't working as expected after gdk_window_create_similar_surface to cairo_image_surface_create change. For whatever reason, this can't paint given area properly if the copy direction is down (we scroll up). In other direction it seem to work. ?!? So we have 4 visible lines and want to scroll one line up, from this state: 2 3 4 5 we should see 1 2 3 4 but will see 1 2 2 2 On scrolling up one line the code in the ruler tries to copy (visible area - line) from the current gc to same gc via bufferGC.copyArea(0, 0, size.x, height + dy, 0, -dy); In the example above we are copying [234] area one line down, but get instead [222] content in the final image. If I replace the code that copies from same gc to gc with the code that creates a temporary image, saves the current image to that one and copies from the temporary image back to original one, shifted by one line, it works! // bufferGC.copyArea(0, 0, size.x, height + dy, 0, -dy); Image tmpImg= new Image(fCanvas.getDisplay(), size.x, size.y); GC tmpGC= new GC(tmpImg); try { bufferGC.copyArea(tmpImg, 0, 0); tmpGC.copyArea(fBuffer, 0, dy); } finally { tmpImg.dispose(); tmpGC.dispose(); }
So in other words: the previous implementation in SWT was smart enough to detect the overlap between src and dst, and copied from the bottom to the top. The new implementation doesn't detect the overlap and just copies from top to bottom, and as result fills everything with the first line.
(In reply to Thomas Wolf from comment #13) > So in other words: the previous implementation in SWT was smart enough to > detect the overlap between src and dst, and copied from the bottom to the > top. The new implementation doesn't detect the overlap and just copies from > top to bottom, and as result fills everything with the first line. I believe this is not SWT fault directly, the most logic how that is copied is in GTK/Cairo, but I believe the difference is in different surface used now by SWT. Probably copying of image areas was working with gdk_window_create_similar_surface doesn't work with cairo_image_surface_create, and may be there is a "right" API in Cairo that isn't yet used by SWT. Or it could be just a bug in Cairo.
@Paul: do you have any idea here? Are you familiar with these cairo APIs?
I am able to reproduce the problem on Ubuntu 20.04. Investigating now
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176289
Created attachment 285565 [details] Patch set 4 issues https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176289/4 Patch set 4 fixes rulers and doesn't crash SWT examples as patch set 3, but it seem to break cell rendering, see attached image.
(In reply to Andrey Loskutov from comment #18) > Created attachment 285565 [details] > Patch set 4 issues > > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176289/4 > > Patch set 4 fixes rulers and doesn't crash SWT examples as patch set 3, > but it seem to break cell rendering, see attached image. @Andrey, Can you please try patch 5?
(In reply to Mickael Istria from comment #15) > @Paul: do you have any idea here? Are you familiar with these cairo APIs? I have no clue to be honest. I'm not super familiar with the cairo APIs either to know the source of this bug. I will try to reproduce and look into this.
(In reply to Sravan Kumar Lakkimsetti from comment #19) > (In reply to Andrey Loskutov from comment #18) > > Created attachment 285565 [details] > > Patch set 4 issues > > > > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176289/4 > > > > Patch set 4 fixes rulers and doesn't crash SWT examples as patch set 3, > > but it seem to break cell rendering, see attached image. > > @Andrey, > > Can you please try patch 5? LGTM, so far I couldn't find any regression and line numbers are back to normal state.
(In reply to Andrey Loskutov from comment #21) > (In reply to Sravan Kumar Lakkimsetti from comment #19) > > (In reply to Andrey Loskutov from comment #18) > > > Created attachment 285565 [details] > > > Patch set 4 issues > > > > > > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176289/4 > > > > > > Patch set 4 fixes rulers and doesn't crash SWT examples as patch set 3, > > > but it seem to break cell rendering, see attached image. > > > > @Andrey, > > > > Can you please try patch 5? > > LGTM, so far I couldn't find any regression and line numbers are back to > normal state. Let me do couple more tests and finalize this.
Merged to master
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176289 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=af9f5cee1641970fa03ce813da7ba1dfc6e94141
(In reply to Eclipse Genie from comment #24) > Gerrit change > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176289 was > merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=af9f5cee1641970fa03ce813da7ba1dfc6e94141 Unfortunately I've just found regression from that commit, see bug Bug 571242.
