Community
Participate
Working Groups
When using GTK 3.10 all views are empty. The problem is caused by a change in the way events are propagated. In previous versions each GtkWidget with a gdkwindow got an expose event which gtk+ internally converted to emitting a draw signal then the widget had to propagate draw to any children that didn't have window. Now (3.10) instead a single expose event on the toplevel and convert to a draw signal, which is propagated to *all* child widgets. Suggestion from gtk developers is to not ever look at expose events, just ignore them and instead intercept the draw signal and that this should work for all GTK 3.x versions.
Easy way to see a change is changing the case for EXPOSE_EVENT in windowProc in Widget from: if (OS.GTK3) { return gtk_draw (handle, arg0); } else { return gtk_expose_event (handle, arg0); } to if (!OS.GTK3) { return gtk_expose_event (handle, arg0); } After this change all the content of the few is drawn but not the tab.
We no longer
Saved too early... We no longer hook "expose_event" in GTK3. If you look at Display.initializeCallbacks(), Widget.EXPOSE_EVENT is mapped to "draw" instead of "expose_event". The constant name (Widget.EXPOSE_EVENT) is misleading, but it was the easiest change at the time. Note that Widget.DRAW == Widget.EXPOSE_EVENT. There must be something else going on.
It's CTabFolder problem only as far as I found. If disabling the gtk_draw call in Widget.gtk_draw the drawing reverses - the content of the tabs is drawn but not the tabs and toolbar. Any help is appreciated.
Due to the amount of draw events received compared to way smaller number of expose events I would guess that in the GTK 3 port some functions that emits draw is called making it being received constantly.
I think I identified it to calling Cairo.cairo_reset_clip which is documented to have unpredictable effects when combined with gdk_cairo_create. Silenio, I really need your expertise on the topic to guide me.
Experimental patch to display difference in rendering in CustomControlExample. https://git.eclipse.org/r/20046
Set it to critical as more and more people have gtk 3.10 on their machines.
*** Bug 424714 has been marked as a duplicate of this bug. ***
Something that looks like relevant bug: https://bugzilla.gnome.org/show_bug.cgi?id=700674
*** Bug 423420 has been marked as a duplicate of this bug. ***
I'm investigating the problems with GTK versions >= 3.10 and hope to be able to find a fix in a week or two.
Something that might be related. If one runs Snippet294 it looks like the region is set correctly but the Shell background is not painted on that region. If background is painted on top of children it might explain the empty looking views.
I have investigated this problem (running gtk 3.10.6). Here are my conclusions so far: 1) the behavior of cairo_get_matrix() has changed. The cairo object is now reused for all views inside the root window and it includes a translation relative to the root. This causes problems to GC.getClipping(). The matrix needs to be the identity when a GC is created. I hacked all calls to cairo_get_matrix() to try to work around the problem (will attach patch). 2) the drawing of the views (tree contents) fails after a call to GC.fillPolygon() with a point array with more than 80 elements. If I avoid that call, the contents of the tree draws properly. I will attach a patch with my hacks. Arun/Alex, could you confirm that the patch also improves the situation for you?
Created attachment 239227 [details] hacks
Silenio, it definetely improves things (views has contents). But CTabFolder min/max and toolbar are not visible for me.
The order of GTK "draw" signal is bottom-up. It comes first to the child in than to the parent. I do not think this order has changed in gtk 3.10 (need to check), but it seems that the cairo object sent in the "draw" signal for the parent no longer is clipped against the children. So drawing done on the parent overwrites the drawing done by the children. That is why commenting the fillPolygon() helps, the body of the tab folder was drawn on top of the tree contents. But CTabFolder max/min are still over drawn by the tab folder header. Here is a simple test case that shows the problem. Need to figure out a way to clip the children out. Maybe gdk_window_get_clip_region() will help: import org.eclipse.swt.custom.*; import org.eclipse.swt.graphics.GC; import org.eclipse.swt.layout.GridLayout; import org.eclipse.swt.widgets.*; import org.eclipse.swt.*; public class Main { public static void main(String[] args) { final Display display = new Display(); Shell shell = new Shell(display); Canvas canvas = new Canvas(shell, SWT.NONE); canvas.setBackground(display.getSystemColor(SWT.COLOR_BLUE)); canvas.setBounds(100, 100, 500, 400); canvas.addListener(SWT.Paint, new Listener() { public void handleEvent(Event event) { System.out.println("paint canvas"); GC gc = event.gc; gc.setBackground(display.getSystemColor(SWT.COLOR_GREEN)); gc.fillPolygon(new int[]{7, 0, 6, 0, 5, 0, 4, 1, 3, 1, 2, 2, 1, 3, 1, 4, 0, 5, 0, 6, 0, 143, 0, 144, 0, 145, 1, 146, 1, 147, 2, 148, 3, 149, 4, 149, 5, 150, 6, 150, 850, 150, 851, 150, 852, 150, 853, 149, 854, 149, 855, 148, 856, 147, 856, 146, 857, 145, 857, 144, 857, 7, 857, 6, 857, 5, 856, 4, 856, 3, 855, 2, 854, 1, 853, 1, 852, 0, 851, 0, 7, 0}); } }); Tree tree = new Tree(canvas, SWT.NONE); for (int i = 0; i < 4; i++) { TreeItem item = new TreeItem(tree, SWT.NONE); item.setText("Item" + i); } tree.setBounds(20, 30, 200, 300); tree.addListener(SWT.Paint, new Listener() { public void handleEvent(Event event) { System.out.println("paint tree"); } }); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
Since 423420 has been marked as a duplicate of this bug, I want to mention that the workbench freezes completely when debugging in the second instance. The problem is reproducible, if GTK3 is enabled - at least on my machine with the relatively old GTK 3.6.4.
I've just posted attachment 239318 [details] to bug 424657 comment 11 but few bug reports later realized that this bug fits better. I see no content (tables/scroll panes) in Eclipse configuration dialog with GTK3. With GTK2 everything is there. However views are not empty.
It appears that when "org.eclipse.product" is not available (so that there is no CSS enabled) the tree item appear and work correctly with Fedora 20. From this, I tend to believe that the bug is actually a bug in CSS engine which probably use bad SWT operation on the tree to apply a style.
PS: Thanks Victor Rubezhny for this catch. The story is that running tests with Tycho surefire (not using the org.eclipse.platform product nor CSS) against a Luna M5 target-platform works well, whereas packaged IDE fails.
Potential places to fix/workaround this: * the CSS theme contains an operation that makes Tree failing with GTK 3.10+. CSS file could be changed to avoid this (workaround) * CSS engine probably does something wrong with existing tree (or container) * SWT doesn't allow an operation use by CSS Engine
(In reply to Mickael Istria from comment #20) > It appears that when "org.eclipse.product" is not available (so that there > is no CSS enabled) the tree item appear and work correctly with Fedora 20. > From this, I tend to believe that the bug is actually a bug in CSS engine > which probably use bad SWT operation on the tree to apply a style. I see this issue also if the CSS stylesheets are available.
(In reply to Mickael Istria from comment #22) > Potential places to fix/workaround this: > * the CSS theme contains an operation that makes Tree failing with GTK > 3.10+. CSS file could be changed to avoid this (workaround) the problem is also apparent when using the jeeeyul theme (just as a side note)
Workaround #1: Go to Window > Preference > Appearance and chose "Classic" instead of GTK.
(In reply to Mickael Istria from comment #25) > Workaround #1: Go to Window > Preference > Appearance and chose "Classic" > instead of GTK. With this workaround, views aren't empty, but whenever you expand a tree node in the Package Explorer, all labels and icons disappear...
Workaround 2: Get a fresh Eclipse Luna M5. Open plugins/org.eclipse.platform_*/css/e4_basestyle.css, and comment line 9 (the one about CTabRenderer). Start Eclipse. Enjoy.
Shouldn't this bug be put in the e4 renderer basket then?
(In reply to Mickael Istria from comment #28) > Shouldn't this bug be put in the e4 renderer basket then? If CTabRendering works on some GTKs but not others, that seems to indicate an SWT problem, as I wasn't able to find any OS calls in that class. PW
(In reply to Mickael Istria from comment #28) > Shouldn't this bug be put in the e4 renderer basket then? There is definetely an swt problem and the cause for it is known but not the fix yet. What would be nice is if it can be temporarily workarounded in platform.ui till swt is fixed.
Created attachment 239668 [details] Screenshot I see this issue also in Wizard, so I doubt that is only the CTabRendering which is causing this issue. Attached a screenshot of the PointSelectionPage class which is used to select an extension point for an extension in the plugin.xml (screenshot based on the dark theme but I see the same with the GTK theme).
(In reply to Lars Vogel from comment #31) > Created attachment 239668 [details] > Screenshot > > I see this issue also in Wizard, so I doubt that is only the CTabRendering > which is causing this issue. Attached a screenshot of the > PointSelectionPage class which is used to select an extension point for an > extension in the plugin.xml (screenshot based on the dark theme but I see > the same with the GTK theme). Lars, is this the latest I-Build ? This is reported in another bug and I wasn't able to reproduce on GTK 3.8 and 3.10 on Fedora/RHEL. Can you check with latest as few fixes from last week should have fixed that?
(In reply to Alexander Kurtakov from comment #32) > Lars, is this the latest I-Build ? This is reported in another bug and I > wasn't able to reproduce on GTK 3.8 and 3.10 on Fedora/RHEL. Can you check > with latest as few fixes from last week should have fixed that? I tested with Build id: I20140204-0800 and still the same empty dialog.
(In reply to Lars Vogel from comment #33) > I tested with Build id: I20140204-0800 and still the same empty dialog. I believe I could reproduce it with the Open Type or Open Resource dialogs. When there are so many items that the list needs a scroll, nothing is shown (however elements are here as up and down keys seem to change selection and output of the dialog). When you refine filter and the list of available items doesn't require a vertical scroll, then you see this items.
I can confirm this bug. It's really nasty and it happens with 3.10 of GTK and Luna since at least Build id: I20140123-1600. Just try it on ubuntu Trusty Tahr and you will get this nasty effect. Even build classpath panel on config does not show anything but you can use the buttons on right if you click on the panel as if you were seeing each entry. Seems that's just a refresh problem or something related to display more than a functionality bug.
FWIW, F20 is unusable with SWT_GTK3=1. Package Explorer View, Console View etc. all empty. $ rpm -q gtk3 gtk3-3.10.6-1.fc20.x86_64 $ rpm -q eclipse-platform eclipse-platform-4.3.1-11.fc20.x86_64
Great! If I use SWT_GTK3=0 before the executable I can make it work. Surely because it does not use gtk v3 so it's not using native widgets. Anyway it's a workaround that works well...
(In reply to Silenio Quarti from comment #17) > The order of GTK "draw" signal is bottom-up. It comes first to the child in > than to the parent. I do not think this order has changed in gtk 3.10 (need > to check), but it seems that the cairo object sent in the "draw" signal for > the parent no longer is clipped against the children. So drawing done on the > parent overwrites the drawing done by the children. That is why commenting > the fillPolygon() helps, the body of the tab folder was drawn on top of the > tree contents. But CTabFolder max/min are still over drawn by the tab > folder header. This indeed seems to be the case. I have confirmed with a GTK only test snippet that the cairo context from the "draw" signal is behaving differently with GTK+ 3.10 as opposed to its behavior on earlier GTK+ versions. This is a major break in behavior and would likely need to be fixed in GTK+ itself. I have raised a bug for the same - https://bugzilla.gnome.org/show_bug.cgi?id=725089
Created attachment 240317 [details] Another hack. There seems to be a problem with our fixed implementation. Courtesy of Benjamin Otte for this hack which I rebased to our own SwtFixed. With it clipping seems to be fixed but it entirely breaks ControlExample (all tabs are empty). Putting it here for reference and testing.
FYI https://git.gnome.org/browse/gtk+/commit/?id=e2a83cae0f89945cc24464c21a965fc42affe96a
Created attachment 240445 [details] Screenshot FYI - Launching tab in the product editor is also empty
I have put in a patch which forces Eclipse to use GTK+ 2.x (irrespective of the value of the SWT_GTK3 variable) libraries when the version of the available GTK+ 3.x libraries is >= 3.9.0, until we find a proper fix for this problem. https://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=48cc91881fabe6090deaff9e4998f89134ee1fcc https://git.eclipse.org/c/equinox/rt.equinox.binaries.git/commit/?id=b8729cbfe8b2ea8f54e13cd3cc7bb343ecca4dcc
Reducing severity from 'blocker' for M6 as there is a workaround available in M6 (fallback to GTK+ 2).
*** Bug 429640 has been marked as a duplicate of this bug. ***
The issue happens because GTK >= 3.10 doesn't dispatch an expose event for a non-native window. Eclipse connects a signal handler to the EXPOSE_EVENT and EXPOSE_EVENT_REVERSE event. Then, it handles draw signals when EXPOSE_EVENT is emitted and gets draw signals in the inverse order as described in #c17. Solution: handling the draw signals when emitting the EXPOSE_EVENT_REVERSE event. Attached is a patch. I have tested Fedora 20 (GTK 3.10.4), Ubuntu 13.10 (GTK 3.8.6), GTK 3.10.6, GTK 3.12.0, GTK master... Notice: To test, you have to recompile a Eclipse launcher (or use eclipse_XXX.so from Eclipse 4.4M5).
Created attachment 241941 [details] A patch
@Snjezana: Did you have the opportunity to try this patch against older versions of GTK3 as well (eg Ubuntu 12.04 uses GTK 3.4.2) ? Also, you may want to submit this patch using gerrit to ease reviews by SWT committers. First configure a public key if not already done: https://git.eclipse.org/r/#/settings/ssh-keys , then $ git commit -m "Bug 421127: Fix for GTK3 views" --signoff $ git remote add gerrit ssh://speco@git.eclipse.org:29418/platform/eclipse.platform.swt $ git push gerrit HEAD:refs/for/master
I have added https://git.eclipse.org/r/24959
(In reply to Snjezana Peco from comment #48) > I have added https://git.eclipse.org/r/24959 I have no time to try it out, but this patch does not seem right. The SWT.Paint event should be sent to the application code after the widget has drawn its contents. Also, SWT does not connect the "expose-event" signal on GTK3. It connects the "draw" signal (see comment#3).
(In reply to Silenio Quarti from comment #49) > > I have no time to try it out, but this patch does not seem right. The > SWT.Paint event should be sent to the application code after the widget has > drawn its contents. > The SWT.Paint event hasn't been changed. > Also, SWT does not connect the "expose-event" signal on GTK3. It connects > the "draw" signal (see comment#3). I wasn't talking about the "expose-event" signal from GTK, but about the EXPOSE_EVENT and EXPOSE_EVENT_REVERSE events in Eclipse (both of them are connected to the gtk draw signal). Eclipse declares the DRAW event, but doesn't use it. While I was debugging emitting the draw signals from gtk and handling Eclipse events, I noticed that Eclipse received the GTK draw signals as the 19 (EXPOSE_EVENT_REVERSE) event. After applying the patch, all Eclipse views and tabs are shown properly. Could anybody else test the patch? That is easy because the patch changes just a few lines in Widget.java Mickael, I have also tested GTK 3.4.2 (compiled from source) and it works.
(In reply to Silenio Quarti from comment #49) > > I have no time to try it out, but this patch does not seem right. The > SWT.Paint event should be sent to the application code after the widget has > drawn its contents. > I have again checked how GTK sends draw signals. GTK < 3.10 works as follows: - sends "pre draw" signal (Eclipse gets EXPOSE_EVENT_REVERSE - 19) for parent - sends "post draw" signal (Eclipse gets EXPOSE_EVENT - 18) for parent - sends "pre draw" signal for children - sends "post draw" signal for children GTK > 3.10 works in the following way: - sends "pre draw" signal for parent - sends "pre draw" signal for children - sends "post draw" signal for children - sends "post draw" signal for parent If we call gtk_draw when a "post draw" signal for a widget has arrived, the widget has allready been painted for all its children so it draws its content over them. I have changed the patch so that gtk_draw is called for a widget that isn't a container when a "post draw" signal (EXPOSE_EVENT) arrives, i.e., painting a non-container widget hasn't been changed. gtk_draw is called when a "pre draw" signal gets only for containers. The change is limited to GTK >= 3.9.0.
Created attachment 242048 [details] Picture showing conflict This patch does not apply on 'master'.
@Dani: wrong bug ;)
(In reply to Mickael Istria from comment #53) > @Dani: wrong bug ;) Indeed! Thanks.
I have found the following two issues on GTK3: 1) If you try CustomControlExample with GTK >= 3.10, the tabs in the CTabFolder group won't be shown. I suppose the same issue is described in comment #c14. The issue occurs because GTK >= 3.10 adds the same cairo object to all container's children. SWT invalidates it. Solution: forcing SWT to create a new cairo whenever getting a draw signal (Control.gtk_draw). 2) The issue can also be faced in CustomControlExample. The tab content isn't shown. The issue happens in any GTK3 versions. GTK2 and GTK3 return different values for the height of a ToolBar control. You can see tabs in GTK3 are higher. That's why the content of a tab folder isn't visible in GTK3. Solution: calling the getParent().layout method whenever tabHeight is changed (CTabControl.runUpdate). I have added two new patches: https://git.eclipse.org/r/25290 https://git.eclipse.org/r/25291
Yet another issue is that SWT can paint out of a widget area. The issue can be reproduced when opening a form editor (Manifest editor, for instance). If a page has a scrolled area, it won't be painted correctly. The https://git.eclipse.org/r/25411 fixes the issue.
(In reply to Snjezana Peco from comment #56) > Yet another issue is that SWT can paint out of a widget area. > The issue can be reproduced when opening a form editor (Manifest editor, for > instance). If a page has a scrolled area, it won't be painted correctly. > > The https://git.eclipse.org/r/25411 fixes the issue. Can you please add this comment on bug 427511 ? I also think it's worth amending the commit message to show bug 427511 in the title.
(In reply to Mickael Istria from comment #57) > (In reply to Snjezana Peco from comment #56) > > Yet another issue is that SWT can paint out of a widget area. > > The issue can be reproduced when opening a form editor (Manifest editor, for > > instance). If a page has a scrolled area, it won't be painted correctly. > > > > The https://git.eclipse.org/r/25411 fixes the issue. > > Can you please add this comment on bug 427511 ? I also think it's worth > amending the commit message to show bug 427511 in the title. This is another issue.
Thanks for the patches Snjezana! I have tested and pushed the submitted patches and they seem to solve a majority of the problems and Eclipse is fairly usable now on GTK 3.10+ but it is still not in a completely usable state IMO, mainly because of bug 427480 (which affects all the views in Eclipse which use Trees for displaying their content). So, I've decided to continue with GTK2 as the default for now (when GTK >= 3.9.0), and changed the code so that GTK3 is used when SWT_GTK3=1 is set (refer bug 432490), to make testing with GTK 3.10+ easier.
(In reply to Arun Thondapu from comment #59) > Thanks for the patches Snjezana! I have tested and pushed the submitted > patches and they seem to solve a majority of the problems and Eclipse is > fairly usable now on GTK 3.10+ but it is still not in a completely usable > state IMO, mainly because of bug 427480 (which affects all the views in > Eclipse which use Trees for displaying their content). Can you please post the links to the commits in the Bug reports as reference for others? I think the relevant commit was in this case https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=95182ccd2908446c4a49064e442c7923c70e257f > So, I've decided to continue with GTK2 as the default for now (when GTK >= > 3.9.0), and changed the code so that GTK3 is used when SWT_GTK3=1 is set > (refer bug 432490), to make testing with GTK 3.10+ easier.
Marking this bug as resolved now as the original problem mentioned here is fixed.
Below patch pushed in comment 55 has caused an issue in CTabFolder performance while adding new Tab, refer bug 460744: https://git.eclipse.org/r/#/c/25291/
New Gerrit change created: https://git.eclipse.org/r/115147
Gerrit change https://git.eclipse.org/r/115147 was merged to [R4_7_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=cc88f00e6edcacde9c9de5e0c31533e2c89a678b
