Bugzilla – Full Text Bug Listing
Created attachment 256094 [details]
snapshot gtk2
Created attachment 256095 [details]
snapshot gtk3
So this works only when not using Cairo as gtk2 also is not transparent if used without org.eclipse.swt.internal.gtk.useCairo=false (In reply to Alexander Kurtakov from comment #3) > So this works only when not using Cairo as gtk2 also is not transparent if > used without org.eclipse.swt.internal.gtk.useCairo=false So how we can get it work with gtk3 and cairo? How can I draw a composite semi-transparent with gtk3 and cairo? How can I use a region for a composite with gtk3 and cairo? Are there any other solutions? So for Windows and Linux (with gtk2 and without cairo) it works. Are there no efforts to get the same working for gtk3 with cairo? Thanks in advance If reverting bug 368543 - gtk2 version works even with cairo but the implications of this can be bigger than expected. Arun, any idea about it? This crashes on GTK3 as of master today. We should investigate. So a few things: 1) This crashes on GTK3.10+ because once we try to clip the Cairo region, the region is disposed and the snippet segfaults. I can add an extra guard here to prevent this but that still doesn't solve the bug. 2) Running this on GTK2 doesn't crash but the bug still shows, i.e. it looks like the screenshot in comment 1, but instead the square is 100% opaque. I'll continue to investigate. To clarify, is the desired behaviour that of the screenshot from comment 1? Or is it supposed to look different? Gerrit change https://git.eclipse.org/r/125055 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=70cce8be1320532905ef82171b46309da5c59bc7 (In reply to Eclipse Genie from comment #9) > Gerrit change https://git.eclipse.org/r/125055 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=70cce8be1320532905ef82171b46309da5c59bc7 Patch is in master now, the snippet behaves as it should (i.e. as it did before with GTK2 using non-Cairo). Eric, it looks like this patch introduces bad regression. Open Git staging view and hover over the entries (or just over the buttons). This let the view flicker pretty often, it makes staging view unusable. I've tried with Adwaita and Clearloock-Phenix themes, both are affected. I will attach the video. Since I'm always working with latest daily SDK builds, this is really annoying - if you don't see a quick solution, could be please revert this patch? Created attachment 274738 [details]
Video showing regression (flicker) in Git Staging view
I'm on RHEL 7.4 GTK gtk3-3.22.10-4.el7.x86_64. I20180628-2000 (on v4906) is OK, I20180629-2000 (v4907) is bad one. Created attachment 274744 [details]
Regression with overview ruler overlaying the rest
I believe there is also another regression coming from this patch: overview editor ruler paints itself over a "floating" views, see attached video.
To reproduce: open String type. Open Call Hierarchy view and minimize it. Right click on "value" field in the Outline and "Open Call Hierarchy" on that field.
The overview editor ruler will paint itself over the view content. There is no way to get rid of this, it is not a paint artifact!
Works fine in SDK-I20180625-1545, broken at least in (tested) SDK-I20180701-2000. I guess this must be this issue too.
Andrey, it's public holiday in Canada so feel free to revert it so tomorrow build is fine and Eric can work on improved version when he is back. (In reply to Alexander Kurtakov from comment #15) > Andrey, it's public holiday in Canada so feel free to revert it so tomorrow > build is fine and Eric can work on improved version when he is back. OK, I will try. Do I need some magic to enforce new SWT tag (native code is involved)? (In reply to Andrey Loskutov from comment #16) > (In reply to Alexander Kurtakov from comment #15) > > Andrey, it's public holiday in Canada so feel free to revert it so tomorrow > > build is fine and Eric can work on improved version when he is back. > > OK, I will try. Do I need some magic to enforce new SWT tag (native code is > involved)? Just revert, everything should be automatic for the regular nightly build. New Gerrit change created: https://git.eclipse.org/r/125336 Gerrit change https://git.eclipse.org/r/125336 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=057518a230cdef1a418482a1ab68b2ed4fdd8af8 (In reply to Alexander Kurtakov from comment #17) > (In reply to Andrey Loskutov from comment #16) > > (In reply to Alexander Kurtakov from comment #15) > > > Andrey, it's public holiday in Canada so feel free to revert it so tomorrow > > > build is fine and Eric can work on improved version when he is back. > > > > OK, I will try. Do I need some magic to enforce new SWT tag (native code is > > involved)? > > Just revert, everything should be automatic for the regular nightly build. Thanks. Reverted. Just discovered, the regression seem to badly affect all form-based editors too. Open any plugin.xml or manifest.mf and you will see the flickering on every page with forms. Oh boy, I have a feeling about what went wrong. Andrey - thanks for reverting, I'll investigate properly tomorrow. (In reply to Eclipse Genie from comment #19) > Gerrit change https://git.eclipse.org/r/125336 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=057518a230cdef1a418482a1ab68b2ed4fdd8af8 Just to confirm: the build I20180702-2000 created with this revert commit works again for me. New Gerrit change created: https://git.eclipse.org/r/125406 Gerrit change https://git.eclipse.org/r/125406 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=089e20dd5dd1cda17e7f3cad6f6838423b58074f (In reply to Eclipse Genie from comment #25) > Gerrit change https://git.eclipse.org/r/125406 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=089e20dd5dd1cda17e7f3cad6f6838423b58074f Version 2 of the fix is in master. I had naively removed the SWT.NO_BACKGROUND flag on all Composites for GTK3.10+ and didn't properly check which effects this would have. Will confirm all is well in tomorrow's I-build. Verified the regression is fixed in I20180703-2000. New Gerrit change created: https://git.eclipse.org/r/134257 Gerrit change https://git.eclipse.org/r/134257 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=fc80edfc2ecb1d9fb5225ca0426992d70aa233ba |
Created attachment 256093 [details] The zip-archiv contains the snippet and screenshots Scenario: We use a half transparent composite with round edges to show a kind of selection for a widget, which is selected to configure it for example. We use the SWT.NO_BACKGROUND option for this composite. To demonstrate this, I have made a short snippet. If you push the button "Toggle overlay", then the overlay composite will be visible. (See snapshots in attachment swt_trans_snippet.zip) We use it on win32 and Linux. Problem: Now we use Debian8 (jessie) and I have to set the following environment variables to get it work: export SWT_GTK3=0 -Dorg.eclipse.swt.internal.gtk.useCairo=false (See swt_transparent_gtk2.sh, snapshot_gtk2_002.jpg in attachment) If I do not set these variables, it does not work. Also the round edges of the composite does not work. (See swt_transparent_gtk3.sh, snapshot_gtk3_002.jpg in attachment) GTK-informations: libgtk-3-0 (3.14.5-1) libgtk2.0-0 (2.24.25-3) I would like to use gtk3, but at this time I have to set SWT_GTK3=0. I think it is a great feature, which should work as default without setting a certain SWT – environment - variable?! Thanks a lot in advance. Best regards Jürgen