Caused me some problems with #651, I can reproduce this by running from an xterm:
./tests/xpra/test_apps/colors.py
closing it then running:
./tests/xpra/test_apps/transparent_colors.py
The window does not get detected as having transparency, with this patch:
--- src/xpra/x11/gtk_x11/window.py (revision 7386)
+++ src/xpra/x11/gtk_x11/window.py (working copy)
@@ -479,6 +479,7 @@
window_types = [gtk.gdk.atom_intern(window_type)]
self._internal_set_property("window-type", window_types)
self._internal_set_property("has-alpha", self.client_window.get_depth()==32)
+ log.info("depth=%s", self.client_window.get_depth())
self._internal_set_property("xid", self.client_window.xid)
self._internal_set_property("pid", pget("_NET_WM_PID", "u32") or -1)
self._internal_set_property("role", pget("WM_WINDOW_ROLE", "latin1"))
I see:
depth=24 for regular windows
depth=32 for transparent windows
depth=0 for the steps above...
Please verify:
xpra info | grep has-alpha)
Testing against fedora 20 server, 0.15.0 r-7543.
colors.py test app: TypeError: Couldn't find conversion for foreign struct 'cairo.Context'. In every case an xpra info | grep has-alpha returned nothing (I could attach full xpra info file for each if you'd like).
transparent_colors.py, but in each case xpra info | grep has-alpha returned has-alpha=true.
I'll see about getting a 0.14.0 build with the patch, as well as a trunk build with the patch so I can test again... in the meantime, are there any specific apps I should start by testing (which you suspect might see an issue)?
(Also note, I don't see any sign of any colors in either the colors or the transparent_colors test_apps ... they just look like empty windows that I can't actually close, neither with the 'x' close button on the app window nor with a control-z, nor even a control-c.)
I get the following error when trying to run..
You need to install python3-gi-cairo package.
(found from the second google hit here: http://stackoverflow.com/a/11300600/428751)
I'll see about getting a 0.14.0 build with the patch, as well as a trunk build with the patch so I can test again...
No need for patching anything. The fix is in trunk already.
We want to verify that it does something, and that it doesn't break anything.
Trying a yum install python3-gi-cairo I get a No package python3-gi-cairo available. message.
Turning back to google I find a link to python3-gobject-3.10.2-1.fc20.x86_64.rpm, but nothing to cairo for fedora 20. Is this an at all comparable package?
(Also getting cairo related error messages on most of my other tests server side at this point...)
It's probably python3-gobject or gobject-introspection or pygobject3 then.
I tested this scenario using Fedora 20, 0.14.7, and found that the transparent_colors.py window was not drawn correctly -- all colors were solid, no transparency.
Then I pulled the latest code from the xpra repository 0.15.0, r7840, and the transparent_colors.py window drew correctly -- the transparent shades of color were correctly showing through to the background underneath.
However, in both tests, the log message inserted as suggested in the ticket, reported "depth=0" when running the colors.py followed by transparent_colors.py tests in sequence. It showed depth=0 even when the window drew correctly.
The most important thing to verify is that we don't somehow end up detecting windows as transparent when they're not (use xpra info | grep transparency), because that would be expensive (at least with clients that support transparency, which will hopefully soon be all of them with the GTK3 port).
This bug is somewhat similar to #698 for win32. (also GTK getting the depth wrong)
Backport in r7850. Please close after more thorough testing.
Better solution implemented in r8016: use native X11 calls, which never seem to return the bogus values we get from GTK.
Note: transparency was broken by r7972 (and also in 0.14.10), fixed in r8017.
Upon further testing of this ticket, I'm finding this week (since Monday), that any transparent window crashes the client after a few seconds. And that this is not happening with normal windows.
To reproduce, I start the server normally (this is on my Fedora 20, which supports OpenGL), and attach to it, then run transparent_colors.py. The client crashes (the server is still intact). I'm able to reattach, but the crash reoccurs every time I reattach.
So I restart the server, and instead, run colors.py, and the crash does not occur.
I tried the same test with an older version of xpra (trunk 7939), and don't see the issue.
Maybe this is from some recent checkin, and the problem is already known? If not, I'll try to produce some logs and stack traces for the problem.
Re: last comment. I'm not doing anything special with encoding, so it is reporting encoding=h264 when the crash occurs.
@nickc: please bisect it down, and include the client full -d all log. I am not seeing the problem here at all.
There are only 120 commits since r7939, so it should take less than 8 steps to find the problem.
I'll supply the logs in the next comment, but here are the results of the search for the revision that caused the change.
I actually bisected the revisions twice because two changes occurred. The first change was that transparency in the window: "transparent_colors.py" stopped showing (or showing through if you like). At this point, although the window didn't show transparency, it at least didn't crash.
The second change was when the window started to crash the client.
Disabling of transparency happened in revision r7972.
And the crash started to occur (at least for me) with revision r8017.
I've attached the -d all output leading up to the client crash, as well as the gdb py-bt and bt stacktraces.
(edited comment:12 to replace the copies of the changesets with a link by preceding the changeset number with 'r')
Can you please try bisecting between those two revisions with r7972 reverted? Also these changes are pure server-side, so it would be worth testing with a different client version too.
Raising because this should affect the latest release from the v0.14.x branch as of r7978 (v0.14.10). Worth also checking that you are not hitting #717 here (r7974 has now been applied to trunk).
I checked out a r8017 version of the tree and reversed the changes made in r7972 and that does fix the crash, for what it's worth.
This is a different bug, those crashes are already recorded in #717 and should be dealt with there.
I believe this bug is OK, I just cannot get transparency detection to go wrong any more so closing.
Not sure that this is really related, but I'll post it here first.
Running a 0.15.0 r8096 windows client against 0.15.0 r8072 fedora 20 server, I see video players (specifically at vimeo.com) apparently causing tabs of an epiphany browser to break (produces one of those "oops, something went wrong" warnings with a "dead" tab).
When this happens I'm getting the following output client-side:
2014-11-10 16:32:11,476 enable_alpha() cannot handle window transparency on screen <gtk.gdk.Screen object at 0x6f4ea30 (GdkScreen at 0x2371070)>
Should a windows client even be trying to "enable_alpha()"?
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/654