xpra icon
Bug tracker and wiki

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#654 closed defect (fixed)

transparency detection is unreliable

Reported by: Antoine Martin Owned by: Nick Centanni
Priority: blocker Milestone: 0.15
Component: server Version: trunk
Keywords: Cc:

Description

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...

Attachments (3)

all.log (1.1 MB) - added by Nick Centanni 6 years ago.
bt.log (43.2 KB) - added by Nick Centanni 6 years ago.
py-bt.log (11.3 KB) - added by Nick Centanni 6 years ago.

Download all attachments as: .zip

Change History (21)

comment:1 Changed 6 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Priority: majorcritical

Please verify:

  • that 0.14 is affected: that it is possible to get the transparent window to not be detected as transparent as per the steps in the ticket description (you need a client OS that supports transparency to see the lack for transparency problem, I used Fedora 20 - or use xpra info | grep has-alpha)
  • that trunk is fixed as of r7416
  • that this change does not negatively impact any other apps: we really don't want to end up detecting transparency when we should not as this would prevent us from using video encodings for those windows and could be disastrous for performance
Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:2 Changed 6 years ago by alas

Testing against fedora 20 server, 0.15.0 r-7543.

  • Using fedora 20 0.14.5 r-7539 client, 0.15.0 r-7543 client, and 0.14.0 r-6713 client I get the following error when trying to run the 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).
  • Using the 0.14.5 r-7539 and 0.15.0 r-7543 clients, I got the same TypeError? when trying to run the 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.)

comment:3 Changed 6 years ago by Antoine Martin

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.

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:4 Changed 6 years ago by alas

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...)

comment:5 Changed 6 years ago by Antoine Martin

It's probably python3-gobject or gobject-introspection or pygobject3 then.

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:6 Changed 6 years ago by Nick Centanni

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.

Last edited 6 years ago by Nick Centanni (previous) (diff)

comment:7 Changed 6 years ago by Antoine Martin

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.

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:8 Changed 6 years ago by Antoine Martin

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.

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:9 Changed 6 years ago by Nick Centanni

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.

comment:10 Changed 6 years ago by Nick Centanni

Re: last comment. I'm not doing anything special with encoding, so it is reporting encoding=h264 when the crash occurs.

comment:11 Changed 6 years ago by Antoine Martin

Owner: changed from alas to Nick Centanni

@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.

comment:12 Changed 6 years ago by Nick Centanni

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.

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:13 Changed 6 years ago by Nick Centanni

I've attached the -d all output leading up to the client crash, as well as the gdb py-bt and bt stacktraces.

Changed 6 years ago by Nick Centanni

Attachment: all.log added

Changed 6 years ago by Nick Centanni

Attachment: bt.log added

Changed 6 years ago by Nick Centanni

Attachment: py-bt.log added

comment:14 Changed 6 years ago by Antoine Martin

(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.

comment:15 Changed 6 years ago by Antoine Martin

Priority: criticalblocker

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).

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:16 Changed 6 years ago by Nick Centanni

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.

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:17 Changed 6 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

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.

comment:18 Changed 6 years ago by alas

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()"?

Note: See TracTickets for help on using tickets.