incomplete scroll paints when using opengl:gtk
#4201
Comments
|
Can you include a screenshot of the problematic paints? |
|
My desktop background is black, I've redacted some text with 255,0,0 red (i.e., there is no artifact on the titlebar). The black background is "clear". I.e., if I drag that xpra client window over another window, I can see the other window, beneath it through the remote xpra window:
That image was made by moving the kolourpaint window beneath the nextcloud window AFTER the corruption started. The corruption often goes away after resizing or presumably any client repaint of the affected area.
(I do not have pyopengl_accelerate installed).
|
totaam
changed the title
scroll paints when using opengl:gtk
|
I can reproduce it, and I have no idea how to fix it. xpra/xpra/client/gl/gl_window_backing_base.py Lines 646 to 716 in 85ee52e And the current one: xpra/xpra/client/gl/backing.py Lines 596 to 665 in c013b14 |
Ah, is it a Wayland desktop? (then |
|
So, this is a strange one. If I don't make progress, I could disable |
|
opengl=force:native has the same issue (client version 6.0). I'm getting a lot of corruption between different windows (using shadow for a remote desktop). Client version 4.4.5 works correctly. |
|
Same issue when connecting from xpra 6.0-1 client (Arch linux, XFCE/GTK) to either another 6.0-1 server (Arch linux) or v6.0-r0 server (ubuntu 22.04) from xpra stable repository. Previous Arch Setting |
|
Xpra client 6.0 on Windows has this issue, and the v5.0.8 client doesn't, though it successfully used openGL on 5.0.8 |
|
v6.0.1 will have scroll encoding disabled until I can figure out where the problem comes from: a65e0e2 |
|
I had forgotten to disable it again for 6.1: 8c05f44 After adding support for another fast hashing function: google's cityhash and replacing xxh3: diff --git a/xpra/server/window/motion.pyx b/xpra/server/window/motion.pyx
index 1f7928eff3..b5c2beea17 100644
--- a/xpra/server/window/motion.pyx
+++ b/xpra/server/window/motion.pyx
@@ -15,7 +15,7 @@ from xpra.log import Logger
log = Logger("encoding", "scroll")
from xpra.buffers.membuf cimport memalign, buffer_context # pylint: disable=syntax-error
-from xpra.buffers.xxh cimport xxh3
+from xpra.buffers.cityhash cimport cityhash64
from xpra.util.rectangle import rectangle
@@ -124,7 +124,7 @@ cdef class ScrollData:
assert row_len<=rowstride, "invalid row length: %ix%i=%i but rowstride is %i" % (width, bpp, width*bpp, rowstride)
with nogil:
for i in range(height):
- a2[i] = xxh3(buf, row_len)
+ a2[i] = cityhash64(buf, row_len)
buf += rowstride
We can also use the much slower diff --git a/xpra/server/window/motion.pyx b/xpra/server/window/motion.pyx
index 1f7928eff3..74076eb83d 100644
--- a/xpra/server/window/motion.pyx
+++ b/xpra/server/window/motion.pyx
@@ -117,15 +117,18 @@ cdef class ScrollData:
cdef uint64_t *a2 = self.a2
cdef uint16_t i
cdef uint8_t *buf
+ from hashlib import sha256
+ from struct import unpack
with buffer_context(pixels) as bc:
buf = <uint8_t*> (<uintptr_t> int(bc))
assert len(bc)>=min_buf_len, "buffer length=%i is too small for %ix%i with rowstride %i, should be %i" % (
len(bc), width, height, rowstride, min_buf_len)
assert row_len<=rowstride, "invalid row length: %ix%i=%i but rowstride is %i" % (width, bpp, width*bpp, rowstride)
- with nogil:
- for i in range(height):
- a2[i] = xxh3(buf, row_len)
- buf += rowstride
+ for i in range(height):
+ row = buf[:row_len]
+ digest = sha256(row, usedforsecurity=False).digest()
+ a2[i] = unpack(">Q", digest[:8])[0]
+ buf += rowstride
def calculate(self, uint16_t max_distance=1000) -> None:The visual artifacts persists. So it's unlikely to be caused by unexpected 64-bit hash collisions. c4cc39b added the xpra/xpra/server/window/video_compress.py Line 74 in 85c7a36 So the pixels probably aren't getting corrupted in between the time we calculate the checksum and the time we read them since the data is only held in this one image wrapper object? |
cloning the options later meant that may_use_scrolling tagged the image with the boolean 'scroll' to indicate the scroll detection had already been used, but the flag was later lost and scroll detection would run again in some cases, comparing the current image with itself..
* always use an 'XPRA_' prefix for env vars,
* more readable output,
* get the window size as early as possible,
* use the correct cairo format for rgb updates ('rgb24' only means no alpha, 'rgb_format' tells us the number of pixel components)
|
References: Should we be using render buffers instead of textures? |
|
I can't hold up the 6.1.1 release any longer, so |
|
TLDR: use Why do we need to Line 580 in 342dfa0 |
This reverts commit 013123a. This should work properly again with OpenGL.
Describe the bug
With opengl GTK sometimes remote windows appear "clear".
To Reproduce
Steps to reproduce the behavior:
xpra start :$display --start-new-commands=yes --daemon=no --systemd-run=noxpra attach ssh://$user@$host/$display --opengl=yes:gtk -dpainthttp://boats.sf.net(comes with Debian). (I have no clue what this program/game does, I just know that it depends onlibqt5gui5t64on Debian, and I suspect that it's exercising a similar path as nextcloud-desktop). This program can create similar artifacts when you select the red "create mark" button, causing the cursor have an associated circled number that moves with the mouse when the mouse moves; just kind of move the mouse all around the canvas area, eventually the paints get confused. It looks like programs that directly draw on a canvas are having problems (but I do not have a minimal reproducer program).System Information (please complete the following information):
Additional context
Here is the out put of the log with -d paint:
client log
server log
I did trim the log from before the distortion began; I can try to get a more complete log if it would be helpful.
The text was updated successfully, but these errors were encountered: