Community
Participate
Working Groups
Created attachment 252553 [details] short video how it looks like If "General->Appearance->Use mixed fonts and colors for labels" is on (this is on by default), GTK3 Eclipse produces slight visual garbage on scrolling, incrementally increasing on each scroll and disappearing after moving the mouse over or clicking somewhere else in the editor. I believe this is appeared after the fix for bug 446075, but it can be just by accident because I was not able to really use GTK3 Eclipse before the fix for bug 446075. Attached video demonstrates the problem. I'm on Fedora 21, KDE, Eclipse 4.5.0.N20150411-1500 gtk3-3.14.12-1.fc21.x86_64
Still in 4.5 RC1 candidate I20150513-2000. Interestingly enough, as soon as I try to create screenshot and Eclipse window loses the focus, all paint artifacts are lost and I see perfectly clear picture. All this artifacts are appearing if one: 1) Uses default "General->Appearance->Use mixed fonts and colors for labels" 2) Scrolls in any view with mixed font labels like explorer All this artifacts are disappearing if one: 1) changes the view size 2) moves the mouse over damaged regions (artifacts disappear *line by line*) 3) deactivates Eclipse window (open dialog or any other application) Any chance for 4.5 RC2?
Not sure if its specific to the GTK+ version but I'm unable to reproduce the problem on Ubuntu 14.04 with GTK+ 3.10.8. Alex or Leo, do you see this on Fedora 21?
(In reply to Arun Thondapu from comment #2) > Not sure if its specific to the GTK+ version but I'm unable to reproduce the > problem on Ubuntu 14.04 with GTK+ 3.10.8. > > Alex or Leo, do you see this on Fedora 21? Yea, I can reproduce with Gtk3.14 on F21.
*** Bug 469029 has been marked as a duplicate of this bug. ***
I also see this problem when scrolling in Package Explorer. I'm using Eclipse 4.5 (Mars) on Gentoo Linux with gtk+ 3.14.13.
Same bug here. Debian unstable/ gtk 3.16.5
*** Bug 472416 has been marked as a duplicate of this bug. ***
@SWT team: can we consider this for 4.5.1 please?
(In reply to Andrey Loskutov from comment #8) > @SWT team: can we consider this for 4.5.1 please? That would be awesome. I set the target to 4.5.1, SWT team please adjust if you disagree.
Was there any investigation done what is going on?
(In reply to Alexander Kurtakov from comment #10) > Was there any investigation done what is going on? I am currently investigating/attempting to reproduce. I am having some difficulty reproducing on my system (F22), using: Mars 4.5 (20150621-1200 and N20150715-2000) Gtk 3.16.4 Xfce 4.12 Luna 4.4.2 SR2 (Z20150513-1759) Gtk 3.16.4 and 3.14.2 Xfce 4.12 @All Were there any specific steps to reproduce, or was this a general bug present as soon as Eclipse was started?
(In reply to Eric Williams from comment #11) > Were there any specific steps to reproduce, or was this a general bug > present as soon as Eclipse was started? No special steps. Default Java perspective. Package explorer with few projects managed with Git (to see extra label decorations). Scrolling produces garbage.
(In reply to Andrey Loskutov from comment #12) > (In reply to Eric Williams from comment #11) > > Were there any specific steps to reproduce, or was this a general bug > > present as soon as Eclipse was started? > > No special steps. Default Java perspective. Package explorer with few > projects managed with Git (to see extra label decorations). Scrolling > produces garbage. (In reply to Leo Ufimtsev from comment #3) > Yea, I can reproduce with Gtk3.14 on F21. In the mean time I upgraded to F22. (Gnome classic) Now I can't reproduce it on Gtk3.16.4. (I also tried running my Eclipse on a compiled (Gtk 3.14.2)). It might be related to something further underneath gtk. I tried to reproduce on Mate desktop, doesn't occur there either anymore. @Andrey, from your observations, does it occur right away or only once Eclipse has been running for a while? Are you still on F21 at the moment?
I see this behavior (as well as other GTK3 oddities) in my environment: Eclipse Version: Mars Release (4.5.0) Eclipse Build id: 20150621-1200 Ubuntu Vivid 15.04 Kernel 3.19.0-23-generic GTK Version: 3.14.13-0ubuntu1 (libgtk-3-0:amd64) Xserver: 1:7.7+7ubuntu4 (xorg) Video Driver: Radeon 1:7.5.0-1ubuntu2 (xserver-xorg-video-radeon)
I was able to reproduce on Mars using the package explorer only -- will investigate further.
(In reply to Leo Ufimtsev from comment #13) > @Andrey, from your observations, does it occur right away or only once > Eclipse has been running for a while? Right away. All what I need is enough elements in the explorer (Java project->expand lot of JRE packages) to scroll. Works also without Git decorations, plain vanilla SDK build is enough. > Are you still on F21 at the moment? Yes, just tried to reproduce and it is still there. Fedora 21 KDE spin, Eclipse I20150603-2000, gtk3-3.14.13-2.fc21.x86_64. DPI 96, anti-aliasing is on, subpixel rendering RGB, hinting style "full". I've just tried it with my virtual box image of Ubuntu/Unity 15.04, "old" 4.5 I-build I20150430-1445, same picture. libgtk-3 3.14.12-0ubuntu2 And again, I have feeling this appeared somewhere in the middle of the 4.5 milestones.
The issue can probably be reproduced in all GTK versions greater than 3.14 when using Eclipse that supports a tree/table styled label provider. I have reproduced it in Eclipse Mars with GTK 3.14.0, 3.14.12, 3.16.0 and 3.16.5. The issue can't be reproduced in Eclipse 4.4.2 because that versions ignores a styled label provider.
(In reply to Snjezana Peco from comment #17) > The issue can probably be reproduced in all GTK versions greater than 3.14 > when using Eclipse that supports a tree/table styled label provider. > I have reproduced it in Eclipse Mars with GTK 3.14.0, 3.14.12, 3.16.0 and > 3.16.5. > The issue can't be reproduced in Eclipse 4.4.2 because that versions ignores > a styled label provider. Yes this is the case. I have been able to reproduce on Mars' package explorer using Gtk 3.14+.
*** Bug 473158 has been marked as a duplicate of this bug. ***
*** Bug 462514 has been marked as a duplicate of this bug. ***
(In reply to Andrey Loskutov from comment #0) > I believe this is appeared after the fix for bug 446075 This seems to be the case. The issue stops occurring before that commit, and begins to occur immediately after it. (In reply to Snjezana Peco from comment #17) > The issue can't be reproduced in Eclipse 4.4.2 because that versions ignores > a styled label provider. Could you please clarify: are you referring to the JFace notion of a styled label provider?
New Gerrit change created: https://git.eclipse.org/r/52713
@All, I seemed to have narrowed down the issue. In Tree.java, native painting was disabled for Gtk3.14.9 and above. Using native painting causes the issue to disappear. When a paint listener is used, the correct events are still triggered, though garbage text when scrolling is still present when using a paint listener. This isn't a perfect solution, but at least this issue isn't widespread in Eclipse anymore, and Snippets that use paint listeners still retain their functionality. Despite this, the issue is solved in Eclipse: the Package Explorer and Outline (among others) do not use a paint listener. The problem in bug 446075 has not been re-introduced, either. Using native painting by default in Eclipse also seems to solve bug 469277 -- when I was testing the Outline functionality I noticed the icons are no longer being cut off on the right hand side. I will conduct further testing over the next few days.
Created attachment 255486 [details] issue when v/h scrolling in text editor on eclipse 4.5 for the horizontal scrolling
Created attachment 255487 [details] issue when v/h scrolling in text editor on eclipse 4.5 for vertical scrolling
previous screenshot ("issue when h/v scrolling in test editor on eclipse 4.5") taken from machine running linux debian 8 with jdk 1.8 and 4K display (don't know whether actual display does matter). i doesn't mzke me think this is related to tree control... or mixed fonts (?) uname -svpio Linux #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) unknown unknown GNU/Linux java -version java version "1.8.0_51" Java(TM) SE Runtime Environment (build 1.8.0_51-b16) Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode) gnome-shell --version GNOME Shell 3.14.4
(In reply to Son Mising name from comment #26) > previous screenshot ("issue when h/v scrolling in test editor on eclipse > 4.5") taken from machine running linux debian 8 with jdk 1.8 and 4K display > (don't know whether actual display does matter). > i doesn't mzke me think this is related to tree control... or mixed fonts (?) I think this seems to be more of a screen tearing issue than it does a font/tree/label issue. I would open a separate bug for this.
Created attachment 255491 [details] Test snippet to ensure paint item events are sent properly A small test snippet to see if paint item events are being sent correctly. If they are, a tree item with text "This text should be drawn" should appear, with a clickable area to the left of the text, which will print (PaintItem)
@Eric Williams I had opened another case (https://bugs.eclipse.org/bugs/show_bug.cgi?id=472416) but was unable then to get actual video showing the issue ... and andrey has marked that case as duplicate of #465054 on july 15th. @Andrey Loskutov Is it therefore possible to re-open the case #472416 ... and i'll post the videos as attachments on that case #472416 ?
(In reply to Son Mising name from comment #29) > @Andrey Loskutov > Is it therefore possible to re-open the case #472416 ... and i'll post the > videos as attachments on that case #472416 ? I've reopened the bug 472416.
(In reply to Eric Williams from comment #23) > @All, > > I seemed to have narrowed down the issue. In Tree.java, native painting was > disabled for Gtk3.14.9 and above. Using native painting causes the issue to > disappear. When a paint listener is used, the correct events are still > triggered, though garbage text when scrolling is still present when using a > paint listener. This isn't a perfect solution, but at least this issue isn't > widespread in Eclipse anymore, and Snippets that use paint listeners still > retain their functionality. > > Despite this, the issue is solved in Eclipse: the Package Explorer and > Outline (among others) do not use a paint listener. The problem in bug > 446075 has not been re-introduced, either. > > Using native painting by default in Eclipse also seems to solve bug 469277 > -- when I was testing the Outline functionality I noticed the icons are no > longer being cut off on the right hand side. > > I will conduct further testing over the next few days. Before fixing bug 446075 Eclipse was using native painting, i.e., styled label providers were ignored. That was a temporary workaround. The https://git.eclipse.org/r/52713 patch behaves the same way when disabling Preferences>General>Appearance>Use mixed fonts and colors for labels. You won't be able to reproduce the issue in the Package Explorer, Project Explorer, Outline view, but text won't be styled. The issue can be reproduced in the EGit History view that uses the Table widget. If you try the same workaround for the Table widget, the EGit History view will be empty (bug 457828). I think we should apply https://git.eclipse.org/r/48343 (bug 466499) which will make it easier to fix this issue.
Does this problem impact the quick search dialog? The problem I'm seeing is this: 1. Try to quick search for foo - works. Scroll - problem appears as in package explorer. 2. Try to search for bar - works, kind of. The file selector "frame" displays the text from (1) but if you select a row it displays the correct result for bar in file contents "frame". This really breaks the whole quick search experience. Running on Ubuntu 15.04
New Gerrit change created: https://git.eclipse.org/r/57654
https://git.eclipse.org/r/57654 fixes the issue.
*** Bug 477099 has been marked as a duplicate of this bug. ***
Gerrit change https://git.eclipse.org/r/57654 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=e8864687af0d8b59632ee4db335e08148257a53b
Pushed to master. Thanks for the patch Snjezana. Arun, fine with backport?
Created attachment 257338 [details] tree arrows randomly not painted after patch 57654 (In reply to Snjezana Peco from comment #34) > https://git.eclipse.org/r/57654 fixes the issue. Not entirely, or at least it introduces a new issue. The tree arrows are now randomly painted / not painted, see attached video. Disabling the "mixed fonts and colors" fixes painting again. I've tried build N20151017-1500 on gtk3-3.14.15-1.fc21.x86_64 in KDE 4 / Fedora 21. This happens in two different GTK3 themes, so I think this is a new regression.
New Gerrit change created: https://git.eclipse.org/r/58749
The issue happens because GTK3 doesn't always send rendererRender signals to a tree/table when scrolling. It can be reproduced in GTK 3 >= 3.10.0. I have fixed it by forcing a table/tree widget to resize when a scroll event happens. This patch also fixes the issue introduced by fixing bug 466499. Namely, SWT was sending two PaintItem events for a table/tree column in GTK3 >= 3.14.0 I have tested GTK 3.10.8, GTK 3.14.13, GTK 3.16.7 and GTK 3.18.2.
> Namely, SWT was sending two PaintItem events for a table/tree column in GTK3 >= 3.14.0 Namely, SWT was sending two PaintItem events for a table/tree column 0 in GTK3 >= 3.14.0
(In reply to Eclipse Genie from comment #36) > Gerrit change https://git.eclipse.org/r/57654 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=e8864687af0d8b59632ee4db335e08148257a53b This commit was reverted via http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=944455c34ecdc0ccc6c326764af16ef2a6e80caf as it caused bug 480911 on GTK 3.10.
(In reply to Arun Thondapu from comment #42) > (In reply to Eclipse Genie from comment #36) > > Gerrit change https://git.eclipse.org/r/57654 was merged to [master]. > > Commit: > > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > > ?id=e8864687af0d8b59632ee4db335e08148257a53b > > This commit was reverted via > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=944455c34ecdc0ccc6c326764af16ef2a6e80caf as it caused bug 480911 on GTK > 3.10. I have already created a new patch - https://git.eclipse.org/r/#/c/58749/.
I have updated the patch to work in a similar way to GTK2 (within the updateScrollBarValue(ScrollBar) method). GTK3 additionally calls a resize event for the handle widget (tree/table) because the hierarchy in GTK3 has been changed.
Just a note that with Fedora 23, disabling "mixed fonts" makes that a selected completion appears as white text on light gray background, which is not easy to read at all. So it's currently a trade-off: either I use mixed fonts and gets the garbage text on scrolling, or I don't use it and cannot read correctly the completion results. I currently prefer the former, but that's not an ideal solution when showing Eclipse to new people. Can the priority be raised on this issue? I currently feel like I cannot show my Eclipse IDE to new people without highlighting this issue.
Gerrit change https://git.eclipse.org/r/58749 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=fd26f9864345917e47d75d58ef8ebac25c51a016
Alex, you mentioned about concerns with the patch on gerrit, do you think we can backport to 4.5.2?
(In reply to Arun Thondapu from comment #47) > Alex, you mentioned about concerns with the patch on gerrit, do you think we > can backport to 4.5.2? I don't particularly like the queue resize but considering we don't have better fix and that it improves the situation significantly - better to push it.
Snjezana, can you please upload a gerrit patch for the backport to 4.5.2? I'm unable to either cherrypick from gerrit or push directly from my workspace...
New Gerrit change created: https://git.eclipse.org/r/64293
I have created the patch against the R4_5_maintenance branch.
New Gerrit change created: https://git.eclipse.org/r/64636
Gerrit change https://git.eclipse.org/r/64636 was merged to [R4_5_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=cbecf016a9b19d5f182edca97c00cf0786c1639b
Verified in I20160124-0800 on ubuntu 15.10 64bit
This is reported fixed in 4.5.2, however I'm still seeing pretty severe repainting issues, mostly around the line number bar adjacent to the vertical scrollbar when switching editor tabs.
(In reply to Eric Sirianni from comment #55) > This is reported fixed in 4.5.2, however I'm still seeing pretty severe > repainting issues, mostly around the line number bar adjacent to the > vertical scrollbar when switching editor tabs. I think this issue is related to bug 467499.
(In reply to Snjezana Peco from comment #40) > The issue happens because GTK3 doesn't always send rendererRender signals to > a tree/table when scrolling. > It can be reproduced in GTK 3 >= 3.10.0. Could you please explain this a bit further? I've had trouble narrowing this down. It seems in this bug that painting is happening too often when scrolling, thus causing the fuzzy text as text is being painted over itself many times. Is it possible that the render signal is being sent too often, thus sending too many paint events?
(In reply to Eric Williams from comment #57) > (In reply to Snjezana Peco from comment #40) > > The issue happens because GTK3 doesn't always send rendererRender signals to > > a tree/table when scrolling. > > It can be reproduced in GTK 3 >= 3.10.0. > > Could you please explain this a bit further? I've had trouble narrowing this > down. > > It seems in this bug that painting is happening too often when scrolling, > thus causing the fuzzy text as text is being painted over itself many times. > Is it possible that the render signal is being sent too often, thus sending > too many paint events? I have debugged the Tree.rendererRender method that creates the EraseItem, MeasureItem and PaintItem events. The correct order is: MeasureItem, EraseItem, PaintItem. When styled cell providers receive these events in this order, they will paint an item correctly. SWT creates MeasureItem and EraseItem when it recognizes a pixbuf cell renderer and PaintItem when it receives a text cell renderer. GTK2 and GTK3 < 3.10 send a signal for every item (column) and SWT creates events correctly. GTK >= 3.10 doesn't send these signals when a Tree/Table is scrolled fast. I haven't succeeded to find a rule GTK uses to send these events when scrolling a Tree/Table. SWT sometimes recognizes only a pixbuf cell renderer and creates MeasureEvent/EraseEvent. SWT doesn't receive any signals for some visible items. In my opinion, the problem is that GTK doesn't send these signals sometimes and a styled label provider doesn't receive any events or receives just the MeasureItem/EraseItem events.
(In reply to Snjezana Peco from comment #58) > I have debugged the Tree.rendererRender method that creates the EraseItem, > MeasureItem and PaintItem events. > The correct order is: MeasureItem, EraseItem, PaintItem. When styled cell > providers receive these events in this order, they will paint an item > correctly. > > SWT creates MeasureItem and EraseItem when it recognizes a pixbuf cell > renderer and PaintItem when it receives a text cell renderer. > GTK2 and GTK3 < 3.10 send a signal for every item (column) and SWT creates > events correctly. > GTK >= 3.10 doesn't send these signals when a Tree/Table is scrolled fast. I > haven't succeeded to find a rule GTK uses to send these events when > scrolling a Tree/Table. SWT sometimes recognizes only a pixbuf cell renderer > and creates MeasureEvent/EraseEvent. SWT doesn't receive any signals for > some visible items. > > In my opinion, the problem is that GTK doesn't send these signals sometimes > and a styled label provider doesn't receive any events or receives just the > MeasureItem/EraseItem events. Ah, I see. This makes sense to me actually, thanks. I started investigating how the render() function is triggered and didn't find anything conclusive either.
