blank window displayed, underlying actual window has content

[karlkleinpaste]

centos 8, latest *.rpm as of 30min ago.
with this sequence of commands:

  550   01:52pm   xpra start :73 --start-child='vglrun mate-terminal'
  551   01:52pm   xpra attach :73 &
  552   01:53pm   xpra screenshot Desktop/screen1.png
  553   01:53pm   eom Desktop/screen1.png

screenshot shows 3 things:

• left: the regular local terminal from which xpra was started, using above commands.
• center: the displayed xpra-driven mate-terminal.
• right: the image from xpra screenshot.

there's no there there.

xpra's X server believes in window content (right), as recorded by the screenshot subcommand. but what displays in the active mate-terminal window (center) is just an outlined black space.

[totaam]

As far as I can tell, there is no mate-terminal anywhere in the default CentOS repositories.
I've used the closest thing I could find for testing: gnome-terminal and could not see any problems.

I was unable to test with server opengl acceleration (vglrun) since my test environment is a virtualbox VM.

Can you please try:

• without vglrun
• with --opengl=no / yes for the client

And if this doesn't help, please attach xpra info to this ticket.

---

FYI here's a better version for combining your first two command lines:

xpra start :73 --exec-wrapper=vglrun --start=mate-terminal --attach=yes

(using exec-wrapper for vglrun allows the server to see the accelerated virtualgl configuration)

[totaam]

Another idea is that this may be encoding related, perhaps there is a problem with one of the recent changes to the webp encoder: https://github.com/Xpra-org/xpra/commits/master/xpra/codecs/webp

You could ascertain if this is the case by running the client with --encodings=png,jpeg,rgb.

[karlkleinpaste]

What I've learned so far:

• No joy (no change) from --encodings=...
• vglrun, or not, does not matter.
• Since my main machine is f33 with r30351 (because I think you've stopped generating RPMs for f33, now that f35 is out), and I don't see this invisible window problem on f33, I downgraded Centos8's xpra to r30351: Same problem seen at that revision level.
• Same invisible window problem with gnome-terminal, but not any other app. I have tried a wide variety of apps, including every terminal emulator I've got (xterm, konsole, urxvt, ...), and the only 2 apps that demonstrate invisible window problems are gnome-terminal and mate-terminal.
• It doesn't matter whether mate-terminal or gnome-terminal is the xpra startup app: I can use --start-child=xterm, and just running mate-terminal from within the xterm gives me the same invisible window.

I don't know what I'm up against yet. Everything was fine until this past week. The machine runs general dnf update somewhat regularly so I am beginning to wonder (fear) that some other change in the system has led to this. More news as it happens, but I can't afford to spend too much time here.

[karlkleinpaste]

Oh, an important detail: It's not black or blank. It's transparent. Whatever is behind it is seen through the "invisible" window.

I can't yet imagine how this has become sensitive to fail only in Centos8.

[karlkleinpaste]

Running as a different user (root) with a clean, minimal environment fails the same. So it's not my personalized environment causing this.

[totaam]

Oh, an important detail: It's not black or blank. It's transparent.

That's it. Now I think I know where to look.
This is probably caused or related to bae2ccd.
What's happening is that the window claims to be using transparency but it actually doesn't use it.
We try to skip it to save unnecessary bandwidth but perhaps the opacity value ends up being zero instead of full.

Since you're connecting locally, --no-mmap may workaround this issue.
Or perhaps also XPRA_ALPHA=0 xpra attach.

[karlkleinpaste]

Both --mmap=no and XPRA_ALPHA=0 gave me a blank white mate-terminal window: No longer transparent, but not showing the real content, which is still discoverable via xpra screenshot.

[karlkleinpaste]

I do not see how to map commits in the git log to your releases -rXXXXX. Can you tell me in what -rXXXXX release the above-mentioend commit bae2ccd occurred? I intend to downgrade just before that and see what happens.

[totaam]

I haven't forgotten about this bug, it's just difficult for me to spend time on it since I just can't reproduce it in a VM.
(I may have to install centos8 on bare hardware - which takes time and spare hardware, both of which are in short supply)

---

xpra --version gives you both the rXXXXX number and the git commit.
But there is no easy way to go from a git commit to an rXXXXX number. Not without
There is no easy way to reconcile rXXXXX numbers with git commits.
If you have a source tree you can do:

$ ./fs/bin/add_build_info.py src
updated ./xpra/src_info.py with:
* BRANCH               = master
* COMMIT               = g65b49035d
* LOCAL_MODIFICATIONS  = 1
* REVISION             = 30523

[karlkleinpaste]

Blunt bisection through released versions in beta repo:

• r30255 everything works fine
• r30274 terminals gone invisible

Somewhere in between those 2 releases is where this occurred.

[totaam]

Thanks!

So, current master is 249 revisions behind right now.
You would think that this command line should give you the correct revision log for r30255 to r30274:
$ git log --format="%h %B" --oneline -n 269 | tail -n 20

But because of the way git counts revisions... it doesn't. So we have to go the long way around to be safe:

$ wget https://xpra.org/beta/CentOS/8/x86_64/python3-xpra-4.3-10.r30255.el8.x86_64.rpm
$ mkdir r30255; rpmdev-extract -C r30255 xpra-common-4.3-10.r30255.el8.noarch.rpm
$ grep COMMIT r30255/python3-xpra-4.3-10.r30255.el8.x86_64/usr/lib64/python3.6/site-packages/xpra/src_info.py
COMMIT='ga81d9ba48'

$ wget https://xpra.org/beta/CentOS/8/x86_64/python3-xpra-4.3-10.r30274.el8.x86_64.rpm
$ mkdir r30274; rpmdev-extract -C r30274 python3-xpra-4.3-10.r30274.el8.x86_64.rpm
$ grep COMMIT r30274/python3-xpra-4.3-10.r30274.el8.x86_64/usr/lib64/python3.6/site-packages/xpra/src_info.py
COMMIT='g5ac49dcbd'

So the correct range is a81d9ba to 5ac49dc

[totaam]

My initial suspicions are on bae2ccd and 7ba6959 so the commit above allows us to disable this new functionality with:

xpra start --env=XPRA_OPAQUE_REGION=0 ...

This should workaround the problem for you. There's a CentOS 8 beta build at r30524, which is the same as fcd2116.

I've just had another report of a bug with this opaque-region feature, something completely different: it didn't strip the unused alpha.
Since stripping the alpha shouldn't make the window more (or even less) transparent, I'm guessing that it is the client that is trying to use an alpha channel that just isn't there.
I would have expected to be able to reproduce this with gnome-terminal however. And not all client backends may be affected the same way.

[karlkleinpaste]

Success with r30524 and --env=XPRA_OPAQUE_REGION=0
mate-terminal displays normally.
Many thanx.

[MartinSchoenstedt]

I am having a similar problem with lxterminal being transparent. As already mentioned in #3363 this comes with the error message too many items in <class 'tuple'> opaque-region: maximum 4 allowed, but got 8 For comparison I have uploaded the xpra info output of a maximized (and working) lxterminal compared to the windowed transparent lxterminal (and indeed opaque-region has length 8)
lxterminal_windowed.txt
lxtermina_maximized.txt

Updating my client on Windows 10 to 4.3-r30590 (ge4a55c82d) 64-bit and setting --env=XPRA_OPAQUE_REGION=0 did not solve the problem. The server is running 4.3-r30335 on Ubuntu 18.04

[totaam]

@MartinSchoenstedt the env var should be applied server-side.

[totaam]

BTW, it would really help if any of you could post the server's -d compress log of when the window is not displaying properly so that I can narrow it down a bit.
(and also try the client with --opengl=force / --opengl=no to see if there are any differences in behaviour)

[MartinSchoenstedt]

the env var should be applied server-side.

I am not quite sure how to do this, I start the xpra server using ssh with the following command C:\"Program Files"\Xpra\Xpra_cmd.exe start ssh://[user]@[ip-addr]:22 --input-method=ibus --start-env=GTK_IM_MODULE=ibus --start lxterminal
I have modified the start-env option to XPRA_OPAQUE_REGION=0 but the problem persists. Also opengl options did not make a difference.

post the server's -d compress log

I am also not quite sure how to get this, as I usually start the xpra server using the above-mentioned command

[totaam]

@MartinSchoenstedt

• FYI: ibus is now the default input method in 4.3: switch input method to ibus? #2359 (comment)
• start-env should be propagated to your server's start command, you can verify that this is the case:

xpra info | grep OPAQUE

I am also not quite sure how to get this, as I usually start the xpra server using the above-mentioned command

Depending on your distro and version, the server log file may end up in $XDG_RUNTIME_DIR/xpra/$DISPLAY_NO/server.log or ~/.xpra/$DISPLAY_NO/server.log.
Another good reason for starting the server separately when debugging is that the command output will tell you where it lives.

[MartinSchoenstedt]

Thanks for your tips. I was now able to get the log file.

server.log

[totaam]

@MartinSchoenstedt Ah. This one is easy!
From your log:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/xpra/server/window/window_source.py", line 1591, in expire_delayed_region
    self.may_send_delayed()
  File "/usr/lib/python3/dist-packages/xpra/server/window/window_source.py", line 1762, in may_send_delayed
    self.do_send_delayed()
  File "/usr/lib/python3/dist-packages/xpra/server/window/window_source.py", line 1779, in do_send_delayed
    self.send_delayed_regions(delayed)
  File "/usr/lib/python3/dist-packages/xpra/server/window/window_source.py", line 1796, in send_delayed_regions
    self.do_send_delayed_regions(dr.damage_time, dr.regions, dr.encoding, dr.options)
  File "/usr/lib/python3/dist-packages/xpra/server/window/window_video_source.py", line 777, in do_send_delayed_regions
    super().do_send_delayed_regions(damage_time, regions, coding, options)
  File "/usr/lib/python3/dist-packages/xpra/server/window/window_source.py", line 1886, in do_send_delayed_regions
    if not self.process_damage_region(damage_time, region.x, region.y, region.width, region.height, actual_encoding, options, flush=i):
  File "/usr/lib/python3/dist-packages/xpra/server/window/window_video_source.py", line 882, in process_damage_region
    image = self.get_damage_image(x, y, w, h)
  File "/usr/lib/python3/dist-packages/xpra/server/window/window_source.py", line 1936, in get_damage_image
    r = rectangle(*opr)
  File "xpra/rectangle.pyx", line 28, in xpra.rectangle.rectangle.__init__

This has already been fixed 7 days ago: 76410f3.
Aren't there any newer builds for your distribution?

[MartinSchoenstedt]

Good to hear, but no newer build was available. I downloaded the latest version for bionic today which was still r30335

[totaam]

the latest version for bionic today..

Ah!
Just started making some new builds, Ubuntu Bionic is there, other distros will land later.

[totaam]

@MartinSchoenstedt / @karlkleinpaste is the XPRA_OPAQUE_REGION=0 workaround still needed with the latest builds? (r30607 and later)

[karlkleinpaste]

Good news, I removed that and terminals don't go transparent.
How was the problem fixed?

[totaam]

@karlkleinpaste the problem was immediately obvious in the server log, see #3354 (comment)
We were mistakenly assuming that the opaque region was a single region (it was with the applications I was testing with!) whereas in fact it can be a list of regions.
Your mate-terminal uses multiple regions and this triggered a bug which prevented any screen update from being sent out.