Xpra-Python3-x86_64_3.0-r22768\xpra_cmd" attach ssh://user@ip/0 --opengl=no --min-quality=20 --desktop-scaling=0.50 2019-05-24 14:03:42,859 Xpra GTK3 client version 3.0-r22768 64-bit 2019-05-24 14:03:42,862 running on Microsoft Windows 10 2019-05-24 14:03:42,962 Warning: failed to import opencv: 2019-05-24 14:03:42,963 No module named 'cv2' 2019-05-24 14:03:42,963 webcam forwarding is disabled 2019-05-24 14:03:44,580 GStreamer version 1.16.0 for Python 3.7.3 64-bit 2019-05-24 14:03:45,373 keyboard settings: layout=us 2019-05-24 14:03:45,378 desktop size is 1600x900 with 1 screen: 2019-05-24 14:03:45,378 Default (423x238 mm - DPI: 96x96) workarea: 1600x860 2019-05-24 14:03:45,379 (Standard monitor types) Generic PnP Monitor (309x174 mm - DPI: 131x131) 2019-05-24 14:03:45,379 downscaled to 50%, virtual screen size: 3200x1800 2019-05-24 14:03:45,379 Default (423x238 mm - DPI: 192x192) workarea: 3200x1720 2019-05-24 14:03:45,380 (Standard monitor types) Generic PnP Monitor (309x174 mm - DPI: 263x262) 2019-05-24 14:03:54,783 enabled remote logging 2019-05-24 14:03:54,784 Xpra GTK2 shadow server version 3.0-r22763 64-bit 2019-05-24 14:03:54,785 running on Linux Ubuntu 16.04 xenial 2019-05-24 14:03:54,791 Attached to 172.16.57.121:22 2019-05-24 14:03:54,792 (press Control-C to detach)
Server has 3 monitors: 2560x1440+0+0, 1920x1080+2560+0, 1920x1080+4480+0
I am starting the shadow server like so ticket:2250#comment:1 (so that I keep CPU running cooler); however, I see huge delays in drawing the monitors/windows :0.[12]
(something even like 1 minute), but no visible delay on :0.0
.
I don't know what else information to provide, so please advise :/
It appears that "data arrives", but probably xpra "becomes lazy" and forgets to repaint the windows other than :0.0
It appears that "data arrives", but probably xpra "becomes lazy" and forgets to repaint the windows other than :0.0
How did you ascertain that the "data arrives"?
As per wiki/ReportingBugs, please include xpra info.
What does the server show when running with -d compress
?
There should be packets for all monitors at regular intervals.
The client's -d draw
log should have matching events.
Does the windows refresh if you request it from the tray menu?
Does it help if you minimize then restore them?
I can reproduce, with all clients (win32 and Linux, python2 and python3, etc) and all servers.
Not sure if this is having an effect yet:
XPRA_SHADOW_REFRESH_DELAY=200
The compressed packets are being sent for the other windows, but somehow nothing actually updates until I click on the first window! Looks like the paint update for the first window triggers the repaint for the other windows. (giving it focus doesn't do it)
Replying to Antoine Martin:
It appears that "data arrives", but probably xpra "becomes lazy" and forgets to repaint the windows other than :0.0
How did you ascertain that the "data arrives"?
I see the network graph, and I have a network graph from the adaptor. "Some traffic" flows, and AFAIK no other traffic is active
As per wiki/ReportingBugs, please include xpra info. What does the server show when running with
-d compress
? There should be packets for all monitors at regular intervals.The client's
-d draw
log should have matching events.
Attaching all data now. While I do see compress/draw
events on the terminal, I don't see them on-screen.
Also, while doing -d compress
only, the client kept sending "server inactive" logs, which arrived in perfect order and timing. But server/client failed to send/draw new frames from the shadow
Does the windows refresh if you request it from the tray menu?
Haven't tried it, and sometimes it is tricky to see that. It seems that client is drawing frames sometimes out of order, so, you cannot have a cohesive order of events. It seems that "everything happens normally", but client doesn't draw.
Does it help if you minimize then restore them?
It has helped, yes, but it is unreliable.
Replying to Antoine Martin:
I can reproduce, with all clients (win32 and Linux, python2 and python3, etc) and all servers.
Not sure if this is having an effect yet:
XPRA_SHADOW_REFRESH_DELAY=200
I don't think so. I've started with plain xpra shadow 0
The compressed packets are being sent for the other windows, but somehow nothing actually updates until I click on the first window! Looks like the paint update for the first window triggers the repaint for the other windows. (giving it focus doesn't do it)
First window "works enough times". The other ones are only getting frames
I also have a workaround solution for that: Minimize all other windows.
Then, :0.0 works *perfectly*
I see the network graph, and I have a network graph from the adaptor. "Some traffic" flows, and AFAIK no other traffic is active
Right, so "some data" is flowing, but you didn't really know what.
the client kept sending "server inactive" logs
What does this mean? "server inactive"? What does it look like?
Turns out that the problem is client side, and opengl makes no difference.
Using XPRA_FORCE_IMMEDIATE_PAINT=1
and XPRA_REPAINT_ALL=1
does not help.
And using a different encoding does not help either.
With opengl disabled the draw + paint processing looks like this:
process_draw: 347945 bytes for window 6, sequence 9, 800x600 at 1280,0 using png encoding with options={} draw_region(1280, 0, 800, 600, b'png', 347945 bytes, 0, {}, [<function WindowClient._do_draw.<locals>.record_decode_time at 0x7fc189a23a60>, <function ClientWindowBase.draw_region.}}}
After clicking in the first window, the draw packet processing for both windows looks like this:
process_draw: 346870 bytes for window 6, sequence 34, 800x600 at 0,0 using png encoding with options={} draw_region(0, 0, 800, 600, b'png', 346870 bytes, 0, {}, [<function WindowClient._do_draw.<locals>.record_decode_time at 0x7fc1887782f0>, <function ClientWindowBase.draw_region.}}} The key difference is the coordinates, the second window has an offset which should not be there!
Replying to Antoine Martin:
I see the network graph, and I have a network graph from the adaptor. "Some traffic" flows, and AFAIK no other traffic is active
Right, so "some data" is flowing, but you didn't really know what.
True. It seems hard to follow the logs, and I want to believe that network graphs are accurate :/
the client kept sending "server inactive" logs
What does this mean? "server inactive"? What does it look like?
Apologies, I should have used the exact message:
64 │ 2019-06-19 14:21:54,719 client @14.750 server is not responding, drawing spinners over the windows 65 │ 2019-06-19 14:21:54,741 client @17.000 server is OK again
It's just sometimes they are "hard to come by" when creating the tickets.
So: client sends the above messages, server receives them "immediately", but, I am not sure why does server or client refuse to exchange packages or draw them. (unless what you found is the root cause)
Bug fixed in r22999: we were losing the rectangle offsets when creating sub-images, which happens when going through the scrolling detection code.
Until the fix lands in a new build, you can workaround the problem by starting your shadow server with:
XPRA_SCROLL_ENCODING=0 xpra shadow ...
(this will make things a lot less efficient, but at least the screen updates will work reliably)
server is not responding, drawing spinners over the windows
This is an unrelated issue. Please file a separate ticket for that.
Replying to Antoine Martin:
server is not responding, drawing spinners over the windows
This is an unrelated issue. Please file a separate ticket for that.
I will wait for when the new builds land, before reporting this
64 │ 2019-06-19 14:21:54,719 client @14.750 server is not responding, drawing spinners over the windows 65 │ 2019-06-19 14:21:54,741 client @17.000 server is OK againSo: client sends the above messages, server receives them "immediately", but, I am not sure why does server or client refuse to exchange packages or draw them. (unless what you found is the root cause)
I'd like to clear up my tickets a little bit, and the time I get to "play" with xpra
these days is pretty limited.
You also fixed small things like r22984 (which I was thinking to report [1]), r22993 etc which don't sound half bad.
[1] it's really important now that I am shadowing my WQHD display to a HD+ laptop screen
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2308