RGB24/32 encoding will rendering black background as transparent

[GUAN-Xihao]

Describe the bug
RGB24 encoding will render black background as transparent

To Reproduce
Steps to reproduce the behavior:

1. xpra start -d video,compress
2. xpra attach --encodings=rgb24 xpra attach --encodings=rgb32 (Note for readers: Please do not use the encodings option in normal use, as this will prevent xpra's heuristic automatic encoding selection, it is only used here for testing. )
3. run xeyes
   

Let's re-run xpra client without --encoding ; run xpra attach

It's black.

System Information (please complete the following information):

• Server OS: RockyLinux 8
• Client OS: Windows 11 with Intel 12th Gen iGPU only.
• Xpra Server Version 6.2.2
• Xpra Client Version 6.2.2 (Full build)

Additional context
If you do not use --encodings=rgb24, it can still be triggered, but you have to wait for the heuristic automatic encoding selection to pick rgb24.

Workaround as of now
Use --encodings=no-rgb24,no-rgb32 for now to disable these two encodings.

[totaam]

That's odd, I will have to check this.
Normally, windows with transparency are sent using webp - which handles transparency just fine.
rgb24 should never be selected for windows with transparency as it will drop the alpha channel.
rgb32 should always work, as it doesn't modify the data in any way.

[GUAN-Xihao]

I have a question, what is the expected behavior for Xeyes on Xpra?
Should the Xeyes window be transparent on Xpra or not?

[totaam]

Yes, it should work just fine.
Must be a recent regression.

I just remembered, xeyes uses xshape and not an alpha channel.
But it should still work.

[totaam]

I just remembered that this is only implemented for X11:

xpra/xpra/client/gtk3/window_base.py

Lines 1256 to 1259 in 83c59af

	def set_shape(self, shape) -> None:
	shapelog("set_shape(%s)", shape)
	if not HAS_X11_BINDINGS or not XSHAPE:
	return

This is a duplicate of: #893.

I'm a bit confused by your comments on encoding=rgb24.
rgb24 and rgb32 are not valid options for the encoding switch.

[GUAN-Xihao]

I'm a bit confused by your comments on encoding=rgb24. rgb24 and rgb32 are not valid options for the encoding switch.

Typo, it is encodings=rgb24 to force the Xpra use rgb24.

Understandably, XShape is not valid, and that’s fine. However, I’m curious—why do different encodings result in different renderings?

The reason I noticed this issue is that I came across a rendering problem in some closed-source software. Most of the time, it uses H264, but occasionally, small area updates outside the XShape area seem to rely on rgb24/32 for the update region. This results in inconsistent rendering. Given that XShape isn’t supported at the moment, it would be ideal if all encodings produced similar behavior.

For now, to help future readers, I think the workaround --encodings=no-rgb24,no-rgb32 is sufficient.

[totaam]

why do different encodings result in different renderings?

This looks like a bug to me.

For now, to help future readers, I think the workaround --encodings=no-rgb24,no-rgb32 is sufficient.

Turning off all rgb encodings is very wasteful, they are order of magnitudes more efficient for small areas.
Keeping just one might be enough.