screen corruption/green on vscode

[cavedon]

The screen appears corrupted, apparently only when using vscode.
This started happening with the upgrade to xpra 6.1

To Reproduce
Steps to reproduce the behavior:
GDK_BACKEND=x11 xpra start ssh://192.168.86.163 --start code

System Information (please complete the following information):

• Server OS: Ubuntu jammy
• Client OS: Ubuntu jammy
• Xpra Server Version: 6.1-r0-1
• Xpra Client Version: 6.1-r0-1

The problem also happens without GDK_BACKEND=x11.
The problem does not happen with --opengl=no.

xpra bugreport.zip

[totaam]

Wow, that's weird!
The fact that this doesn't happen with opengl=no tells me that it's probably the colorspace conversion using the wrong range.
I suspect that the problem happens with webp encoding.
I had made a note of: d6d59a0 + d06a100 + 28bc4c6
We have unit tests for that, but somehow the colors looked wrong so I had reverted it.

I'll have to take another look.

---

Whilst we're here, this shouldn't occur at all if we had correctly mapped vscode to text content-type, but that needs work: #4248 (from #4243)

[totaam]

@cavedon can you try running your client with XPRA_WEBP_YUV=0 xpra attach ..
Does that make the green tint go away?

[cavedon]

Thank you for the quick reply!
XPRA_WEBP_YUV=0 makes the green tint go away, but the screen corruption persists:

[totaam]

@cavedon that one is easier: I forgot to disable scroll encoding again in 6.1 - this will be in 6.1.1
You can fix this one with --encodings=all,-scroll

[totaam]

I think I may be onto something: the tests insist that the data is "studio" range whereas I can clearly see that it's not.
But the unit tests go through the one shot encode function:

xpra/xpra/codecs/webp/encoder.pyx

Line 668 in 13a130e

def encode(coding: str, image: ImageWrapper, options: typedict) -> Tuple:

Whereas the "studio" range images that I see have a frame number, so they go through the pseudo video encoder at:

xpra/xpra/codecs/webp/encoder.pyx

Line 526 in 13a130e

def compress_image(self, image: ImageWrapper, options: typedict) -> Tuple:

The metadata has a subsampling=YUV420P value, so the image data has been processed by WebPPictureARGBToYUVA in

xpra/xpra/codecs/webp/encoder.pyx

Line 795 in 13a130e

cdef void to_yuv(WebPPicture *pic, WebPEncCSP csp=WEBP_YUV420):

Somehow, these two functions don't produce the same color range?

[cavedon]

Confirming that --encodings=all,-scroll solves the corruption form me, thanks!
Let me know if there is any test I can do to help.

[totaam]

Derp, the shader code was wrong - the bug was introduced in #2467.
This will be included in 6.1.1

Until then, another workaround (apart from XPRA_WEBP_YUV=0) is to use --encodings=all,-scroll,-webp