Bugzilla – Full Text Bug Listing
Created attachment 186482 [details]
Another shot with missing painting on column headers
This makes our build almost unusable, as even swapping to a different view causes the package explorer to be unpainted.
Eric, is there anything we could have done to make this painting problem happen?
I'm on
gtk2-2.22.0-1.fc14.1.x86_64
PW
I have the same problem with the pre-Christmas build that has: org.eclipse.swt.gtk.linux.x86_64_3.7.0.v3717.jar org.eclipse.swt.gtk.linux.x86_64.source_3.7.0.v3717.jar I'll check the vanilla 3.7 M4 PW I ran on 3.7 I20110104-0920 from last week, and I don't see the problem: org.eclipse.swt_3.7.0.v3718.jar org.eclipse.swt.gtk.linux.x86_64_3.7.0.v3718.jar Bogdan, is it possible that our CSS hooks are interfering with painting? Mouse overs seem to force painting, and switching views seem to cause trees to disappear. PW Created attachment 186503 [details]
painting problem effecting editors
I tried out I20110110-1454 on my RHEL5 (GTK 2.10), Silenio's RHEL6 (GTK 2.18) and my Ubuntu 10.10 (GTK 2.22) - I couldn't get the top right control to not paint. Nothing interesting has gone in from SWT that could affect this - and I'm have a large number of CTabFolder changes in my workspace but they aren't out yet. I would suspect GTK 2.22 weirdness. Are you able to make it fail more or less regularly? Can you see if this fails for you using the 1.0 release from July? Come grab me when you get in and we can take a look at your machine together. Let's see if we can arrange to debug it some time this week. PW I have the same problem with 4.1M5 and openSUSE 11.3 KDE4, default theme. rpm -qa | grep gtk gtk2-devel-2.20.1-2.13.x86_64 gtk2-engine-murrine-0.90.3-8.1.x86_64 kcm_gtk-1.1-7.2.x86_64 gtk2-32bit-2.20.1-2.13.x86_64 gtk2-metatheme-sonar-11.3.0-2.3.noarch gtkhtml2-devel-3.30.1-1.8.x86_64 gtk2-2.20.1-2.13.x86_64 gtk2-branding-openSUSE-11.3-3.1.noarch gtk2-engines-32bit-2.20.1-1.6.x86_64 gtk2-engines-2.20.1-1.6.x86_64 PackageKit-gtk-module-0.6.3-5.4.x86_64 gtkhtml2-3.30.1-1.8.x86_64 gtk2-metatheme-gilouche-11.1.2-5.1.noarch python-gtk-2.17.0-4.1.x86_64 gtk2-engine-murrine-32bit-0.90.3-8.1.x86_64 Created attachment 188480 [details]
Part1/3 Reproducible test case, eclipse just started
Created attachment 188481 [details]
Part 2/3 Reproducible test case: one mouse klick into the editor area
Created attachment 188482 [details]
Part 3/3 Reproducible test case, editor maximized and restored
The behaviour is reproducible.
-- start eclipse
-- maximize editor
-- restore editor
The mouse click into the editor area is optional. Without it, the outline will never be available.
In addition, I have xorg-x11-server-Xorg-1.9.3-4.fc14.x86_64 PW it's easily reproducible on my main X server, but even when I launch the same executables/workspace in my VNC session it all works fine. My VNC runs metacity as well, but not the full Gnome desktop. Xorg server problem, maybe? PW the fix from bug 290395 worked for me export GDK_NATIVE_WINDOWS=true PW *** Bug 340099 has been marked as a duplicate of this bug. *** We were hoping the fix for bug 342755 would fix this as well, but as of org.eclipse.swt.gtk.linux.x86_64_3.7.0.v3730 it's still a problem. PW I still have the problem on 4.1 SDK which includes org.eclipse.swt.gtk.linux.x86_64_3.7.0.v3730a.jar PW (In reply to comment #17) > I still have the problem on 4.1 SDK which includes > org.eclipse.swt.gtk.linux.x86_64_3.7.0.v3730a.jar I can confirm the same on Fedora 15 with eclipse-SDK-I20110427-0800-linux-gtk-x86_64.tar.gz (same SWT as Paul). $ rpm -q gtk2 gtk2-2.24.4-1.fc15.x86_64 In a virtual machine running RHEL 6 I don't get the exact same missing-view-toolbar-until-mouseover behaviour but I do get weird drawing if I maximize/restore the editor area as Karl describes. *** Bug 344315 has been marked as a duplicate of this bug. *** At work we tried on gtk2-2.22.0-1.fc14.1.x86_64. Maybe it's IBM JVM related? PW Tried the latest IBM 6 JRE but it still works for me on FC14 x86_64. Paul brought his machine in and we were able to debug the problem. The problem seems to happen on a certain version of the X server - version 1.9.5 (Release Date 2011-03-17) is bad. Version 1.10.1 (2011-04-15) is OK (that's what I'm running on Ubuntu) and older ones are too (also tried 1.7.7 from RHEL6). The problem in 1.9.5 is that the XFillPolygon call fails (most likely it doesn't respect the clipping set on the native window by the gtk window - this is why using "pure" X11 window via GDK_NATIVE_WINDOWS would work). We make use of the fillPolygon call in the e4 tab renderer, hence all of the missing toolbars and weird painting issues. As there could be other versions of X that fail, I'm attaching a snippet that can be used to test if XFillPolygon works as expected on your version of X. Created attachment 194950 [details]
Snippet run on X Server 1.9.5
Picture of failing snippet
Created attachment 194952 [details]
Snippet run on X Server 1.10.1
Picture of snippet winning
Created attachment 194954 [details]
Snippet
Test Snippet
Andrew + Karl: Could you guys give the snippet a try and let me know the results? Thanks! Created attachment 194958 [details]
screenshot from running snippet on F15
I'm on F15 x86_64 and running the snippet with a 3.6.2 Eclipse looks like the 1.9.5 snapshot.
$ rpm -q xorg-x11-server-Xorg
xorg-x11-server-Xorg-1.10.1-11.fc15.x86_64
FWIW, my report in bug 344315 (dup of this one) describes a broken situation on Kubuntu 11.4 with X.Org X Server 1.10.1. More precisely the version is xserver-xorg-core 2:1.10.1-1ubuntu1 Setting GDK_NATIVE_WINDOWS helps. Created attachment 194989 [details]
Outcome of running PR333965
kw@localhost:~/dev/eclipse/ide/4.1M6> rpm -aq | grep xorg-x11-server
xorg-x11-server-7.5_1.8.0-10.3.1.x86_64
on openSUSE 11.3
Stephan, can you run the snippet and post the results? Karl, did you run that snippet locally? (Screenshot looks like you are running Xming, which has its own X server). Created attachment 194994 [details] outcome on xserver-xorg-core 2:1.10.1-1ubuntu1 (In reply to comment #31) > Stephan, can you run the snippet and post the results? Here you are. Buggy as expected. (In reply to comment #31) > Karl, did you run that snippet locally? (Screenshot looks like you are running > Xming, which has its own X server). I run it locally. I am using KDE4 with Oxygen style and Oxygen-Molecule GTK style. Did some more investigation into this and installed Kubuntu 11.04 on an x86_64 machine. As Karl mentioned, Kubuntu runs X 1.10.1 - which was working OK on my Ubuntu 11.04 x86 box. So it seems the other common thread here is that all of the systems that had the drawing bugs were running on x86_64 machines. (Can everyone confirm that?) I'm attaching a GTK snippet written in C which fails on x86_64. This shows that it really isn't a bug at the SWT level. More investigation required... Created attachment 195154 [details]
GTK snippet
(In reply to comment #34) >[...] So it seems the other common thread here is that all of > the systems that had the drawing bugs were running on x86_64 machines. (Can > everyone confirm that?) I'm on x86_64 hardware but with a 32bit + PAE OS: $ uname -a Linux luna 2.6.38-8-generic-pae #42-Ubuntu SMP Mon Apr 11 05:17:09 UTC 2011 i686 i686 i386 GNU/Linux > I'm attaching a GTK snippet written in C which fails on x86_64. This shows that > it really isn't a bug at the SWT level. More investigation required... Oops, that snippet can produce a number of different results on my screen. Interesting :) Created attachment 195166 [details]
polygon running
This is what I get on my system. The only changes I can get, is sometime I get 2 little horizontal yellow lines in the red square, usually after exposing it from behind another window.
xorg-x11-server-Xorg-1.9.5-1.fc14.x86_64
gtk2-2.22.0-1.fc14.1.x86_64
PW
Created attachment 195168 [details]
zip file of screenshots
I let the snippet play tangram for a little while.
All differences are random, no code changes.
Is any of the pictures correct?
My screenshot looks like Paul's. I'm on x86_64. Created attachment 196190 [details]
comparison between x86_64 and i686 on Fedora 14
I compared polygon on both arch. x86_64 and i686
1. F14 on x86_64 (with same xorg-x11-server and gtk2 as Paul's)
2. F14 on i686 (same package Version as 1.) and F14 on x86_64 with GDK_NATIVE_WINDOWS in environment
We have released a property that will cause SWT to use Cairo for all GC operations. This will fix the clipping problem described here as well as the image transform problem described in Bug 345650. This property will be set automatically for x86_64 4.1 builds. I'll post here when a build is available for testing. Thanks! I'll confirm the fix for bug 345650 fixes this on my system tonight. PW I don't seem to have a problem on I20110526-1435. +1 :-) PW With I20110526-2200 I no longer see the no-drawing-until-I-mouse-over-it issue. I do see oddness with the view tabs but this is probably not the same bug. I've put up a screenshot of what I mean here: http://fedorapeople.org/~overholt/41viewstacktabs.png I installed today 4.1.0 RC2 (4.1.0.I20110524-1000). With RC2 "no-drawing-until-I-mouse-over-it" was expected. Afterwards I did following: Help>Check for updates and installed from latest integration build update (4.1.0.I20110528-2200) and restarted. I can confirm that painting problems are history now on at least on my x86_64 system. +1 (In reply to comment #44) > With I20110526-2200 I no longer see the no-drawing-until-I-mouse-over-it issue. > I do see oddness with the view tabs but this is probably not the same bug. > I've put up a screenshot of what I mean here: > > http://fedorapeople.org/~overholt/41viewstacktabs.png I think you are talking about feature described in 4.1-M7's new and noteworthy: http://download.eclipse.org/eclipse/downloads/drops/S-3.7M7-201104280848/eclipse-news-M7.html (look under 4.1 Platform's "Style polish" section) I, too, updated to I20110528-2200 with the following result: initial restart -> NO IMPROVEMENT After adding one line to eclipse.ini (after -vmargs): -Dorg.eclipse.swt.internal.gtk.useCairo=true -> OK This is somewhat expected since my operating system is 32bit, but the hardware is 64bit. Apparently the machine isn't recognized as 64bit so the property is not set automatically. It is still needed, though. If this setup cannot be detected programmatically, I suggest to add a notice up-front advising to edit eclipse.ini accordingly. Created attachment 196843 [details]
Brave new Eclipse
Slightly off topic: Now, that I see the full picture of the new Eclipse
I can say that the styling does NOT play well on KDE (Kubuntu).
Specifically: all buttons have gray backgrounds regardless their container.
Either transparence is not working, or the styling is made with the
assumptions that everything has a gray background by default.
I'm almost sure that my KDE settings are all at their defaults in this regard:
- Style: Widget style: Oxygen
- Colors: Scheme: Default
- GKT+ Appearance: Widget style: oxygen-gtk
(In reply to comment #46) > (In reply to comment #44) > > With I20110526-2200 I no longer see the no-drawing-until-I-mouse-over-it issue. > > I do see oddness with the view tabs but this is probably not the same bug. > > I've put up a screenshot of what I mean here: > > > > http://fedorapeople.org/~overholt/41viewstacktabs.png > > I think you are talking about feature described in 4.1-M7's new and noteworthy: > http://download.eclipse.org/eclipse/downloads/drops/S-3.7M7-201104280848/eclipse-news-M7.html > (look under 4.1 Platform's "Style polish" section) Perhaps the graphical message isn't very clear: what is indented as marking the active part is perceived just as minor graphical glitch. Actually, to my taste there is way too little visual clue directing my eyes to the active part. Please, look at attachment 196843 [details] and answer within 0.1 sec. which is the active part (and in fact with different focus this would be even harder). I know this is off-topic here. Any open bug where this is being discussed? > Perhaps the graphical message isn't very clear: what is indented as > marking the active part is perceived just as minor graphical glitch. > Actually, to my taste there is way too little visual clue directing my > eyes to the active part. > > Please, look at attachment 196843 [details] and answer within 0.1 sec. which is > the active part (and in fact with different focus this would be even harder). > I know this is off-topic here. Any open bug where this is being discussed? Main bug for such issues is (AFAIK) bug 293481 "New look for e4 workbench" which depends on several others. Among them is one still unresolved: Bug 320894 "Hard to see which part is "active" in an inactive stack". (In reply to comment #47) > This is somewhat expected since my operating system is 32bit, > but the hardware is 64bit. Apparently the machine isn't recognized as > 64bit so the property is not set automatically. It is still needed, though. I think that if your OS is 32-bit, then your JVM can only be 32-bit and that's all that SWT sees. Created attachment 196906 [details]
blank in compare editor
The main disappearing content has been fixed for me.
I now occasionally see cheese at the left side of XXX. In this example, the left side of the compare editor. I've seen it in the left side of the java editor, and occasionally on the top 2 toolitems in my minimized stack on the left side of the trim.
PW
Created attachment 197219 [details]
Screenshot depiciting clipping problem with package explorer view
Eclipse 4.1.0 Build id: I20110529-2200
I finally found some time to additionally test newly introduced "useCairo" switch and found out that there are still some painting/clipping difficulties although painting problem described in this bug is gone.
Problem: Package Explorer tree's labels are visible outside out of is's parent view part after edit area is minimized and restored.
How to reproduce:
1. Expand tree in Package explorer so that tree labels are long enough not to fit completely in parent view.
2. Minimize editor area and restore it again
3. the Editor area (after restoring from min. state) is now showing package explorer tree's labels (laying outside of it's clipping area)
(check screenshot).
Created attachment 197220 [details]
Workbench window before and after performing maximize and restore
Eclipse 4.1.0 Build id: I20110529-2200
Problem: After maximizing part stack/area (for example an editor area) and restoring it again all other part stacks (except navigation??) won't be repainted correctly (toolbars and tabs).
How to reproduce:
1. Maximize editor area and restore it again
2. after restoration of editor area almost all workbench's part stacks won't be repainted correctly (with exception of "navigation" part stack). The screenshot shows workbench before (left) and after (right) performing "maximize and restore"
(In reply to comment #51) > (In reply to comment #47) > > This is somewhat expected since my operating system is 32bit, > > but the hardware is 64bit. Apparently the machine isn't recognized as > > 64bit so the property is not set automatically. It is still needed, though. > > I think that if your OS is 32-bit, then your JVM can only be 32-bit and that's > all that SWT sees. I'm not blaming SWT here. But given that (some of) the 64-bit related problems affect this machine, too, users should be informed that they may have to help SWT by manually setting the property, no? (In reply to comment #54) > Created attachment 197220 [details] > Workbench window before and after performing maximize and restore This is the problem described in bug 320500 PW (In reply to comment #52) > Created attachment 196906 [details] > blank in compare editor The easiest way to reproduce this is: 1) minimize the outline and package explorer stacks so the editor area stretches the width of the window. 2) use the package exp minimized icon to open it (expand the fast view until it's height is almost that of the Workbench Window) 3) double click on one or more files. As the editor opens, the editor's 2 left-most rulers display above the still open package explorer left-hand side. The workaround is to start eclipse with GDK_NATIVE_WINDOWS=1 PW (In reply to comment #57) Confirmed. GDK_NATIVE_WINDOWS=1 helps here as well. I don't know whether this is related, but I'm having painting problems in the install new software dialog: the list of features (which should be a tree viewer with checkboxes) is not shown at all, though the features are actually there: if you go on the widget where the list should appear and press the down arrow you see that the "Details" part show the description about the (invisible) feature I'm using Kubuntu Natty 11.04 KDE - Style: Widget style: Oxygen - Colors: Scheme: Default - GKT+ Appearance: Widget style: tried all of the available 3 Eclipse SDK 3.7.0.I20110603-0909 see also the attached screenshot Created attachment 198004 [details]
Install New Software Dialog not showing available features
(In reply to comment #59) > I don't know whether this is related, but I'm having painting problems in the > install new software dialog: the list of features (which should be a tree > viewer with checkboxes) is not shown at all, though the features are actually > there: So if you re-launch your eclipse with GDK_NATIVE_WINDOWS=1 can you still see the problem in the new software dialog? PW using GDK_NATIVE_WINDOWS=1 did not help... but starting eclipse with a brand new workspace made the problem disappear... don't know why... (In reply to comment #62) > using GDK_NATIVE_WINDOWS=1 did not help... This is probably a different bug then. Please open a new bug at https://bugs.eclipse.org/bugs against Eclipse Platform SWT. Please include anything in your log file for your workspace that had the problem. PW Bug 349354 will address the rest of the silliness. PW (In reply to comment #64) > Bug 349354 will address the rest of the silliness. > > PW (In reply to comment #64) > Bug 349354 will address the rest of the silliness. > > PW Putting Bug 349354 into "depends" list would be useful. Milestone is set for 3.7.1 :-( *** Bug 353123 has been marked as a duplicate of this bug. *** Will we ever fix the repaint issues? I'm having quite similar problems, but not with GDK_NATIVE_WINDOWS (but that mode is not usable either for other reasons). Release: 20140224-0627, Kepler Service rel 2, Ubuntu 12.04 LTS (current) on amd64, jdk7u51, Gnome classic desktop 2d. Created attachment 241588 [details]
hover mouse pointer over something where a popup will pop up
hover mouse pointer over something where a popup will pop up, then scroll down using the mouse wheel. The editor area below the popup will not get repainted correctly.
Created attachment 241589 [details]
after scrolling down a tiny bit using the mouse wheel
hover mouse pointer over something where a popup will pop up, then scroll down using the mouse wheel. The editor area below the popup will not get repainted correctly.
Is there any viable non-SWT mode for eclipse? (platform-dependent stuff shipping with Java, who wants such a thing? [tm]) Is this still visible with Neon builds? Shouldn't be with Mars either but to double check. No reply in months. Closing. Please reopen if you still experience it. |
Created attachment 186481 [details] CVS repo exploring view has missing parts of scrollbar and toolbar I picked up I20110110-1454, which is based on the latest 3.7 SWT: org.eclipse.swt_3.7.0.v3718.jar org.eclipse.swt.gtk.linux.x86_64_3.7.0.v3718.jar Switching from another window to eclipse leaves the CVS repo tree 3/4s unpainted, and the CVS repo scrollbar and toolbar for that view are partially unpainted (see image). Hitting print screen fills in the CVS repo tree view :-) PW