Windows→Windows connection: unwanted window transparency

[karlkleinpaste]

Windows to Windows testing. r32011 at both ends.
xpra shadow ssh://winhost from either a cmd window or cygwin bash.

The client window opens and operates as expected. However, it keeps fading into transparency.

As long as the mouse stays in motion, the window stays opaque. But as soon as the mouse stops, the client window fades into transparency so as to see the client machine's desktop. It will just about disappear completely. Move the mouse again, and it goes immediately opaque, until the mouse stops moving. The obvious workaround is to keep jiggling the mouse, but that's obviously not a real solution.

[totaam]

However, it keeps fading into transparency.

I've left it running for a while (win10 to win10), no sign of the window going transparent here.
I have no idea what is going on.

You could try:

• running with XPRA_ALPHA=0
• running with -d metadata - I doubt that we're somehow updating the window's opacity, but who knows

If that doesn't show anything useful.. perhaps run both client and server with -d win32, maybe that will show something.

[karlkleinpaste]

I was beginning to experiment with -d metadata, when I noticed that xpra_cmd was giving the warning:

Warning: vendor 'Intel' is greylisted,
  you may want to turn off OpenGL if you encounter bugs

Huh. Howzaboutthat.

Both Win10 machines in question (client & server) are low-end devices. The server has a Radeon iGPU, the client has an Intel UHD iGPU. And apparently you've noticed funniness about Intel GPUs in the past, so as to give this warning.

I added --opengl=no and the transparency silliness stopped entirely.

I don't know if this is a further bug you want to continue to chase, or if it's just considered documented in the sense of the warning above. I'll leave it to you to decide whether to chase down the problem further or simply close it.

[totaam]

We have an entire section dedicated to that: https://github.com/Xpra-org/xpra/blob/master/docs/Usage/Client-OpenGL.md#intel-driver-issues
(I have added a link to this ticket there)

[totaam]

I am re-opening this because I think I know the cause.

It's an Intel OpenGL bug alright, but:

• we shouldn't be using OpenGL for windows with transparency on MS Windows (it just does not work): transparency with the native opengl backend on win32 #1682
• a shadow server should strip out the alpha channel anyway

[totaam]

@karlkleinpaste can you reproduce the problem with -d compress on the server and -d opengl on the client?
I would like to see what pixel format the server is sending. (it should be BGRX - that's what I get when I test)
Depending on the quality setting used, the opengl client should be displaying it using either:

• for lower quality settings: gl_paint_planar(0, 'webp', webp.YUVImageWrapper(YUV420P:(0, 0, 1600, 1200, 24):3_PLANES), ...
• for higher quality settings: RGB update at (0,0) size 1600x1200 (7680000 bytes) to 1600x1200, using GL zerocopy:memoryview format=RGB / UNSIGNED_BYTE to internal format=RGB8

In both cases, we don't upload any alpha channel, so the window should remain 100% opaque.

The only code path that I am unable to test without having a native MS Windows system to test on is:

xpra/xpra/client/gtk_base/gtk_client_base.py

Lines 1346 to 1360 in edd484a

	if WIN32:
	#these checks can't be forced ('opengl_force')
	#win32 opengl just doesn't do alpha or undecorated windows properly:
	if override_redirect:
	return False
	if metadata.boolget("has-alpha", False):
	return False
	if not metadata.boolget("decorations", True):
	return False
	hbl = (self.headerbar or "").lower().strip()
	if hbl not in FALSE_OPTIONS:
	#any risk that we may end up using headerbar,
	#means we can't enable opengl
	return False
	return True

(the only check that could possibly trigger from this chunk is the window has-alpha flag which we can see with -d metadata - it should be False for shadow servers IIRC)

[totaam]

Not heard back.