xpra icon
Bug tracker and wiki

Opened 2 months ago

Closed 5 weeks ago

Last modified 5 weeks ago

#2308 closed defect (fixed)

xpra shadow has huge drawing delays

Reported by: stdedos Owned by: Antoine Martin
Priority: critical Milestone: 3.0
Component: server Version: 2.5.x
Keywords: Cc:

Description (last modified by Antoine Martin)

Xpra-Python3-x86_64_3.0-r22768\xpra_cmd" attach ssh://[email protected]/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 :/

Attachments (1)

xpra-2308-compress-draw.zip (82.4 KB) - added by stdedos 5 weeks ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 2 months ago by stdedos

It appears that "data arrives", but probably xpra "becomes lazy" and forgets to repaint the windows other than :0.0

comment:2 Changed 2 months ago by Antoine Martin

Description: modified (diff)
Owner: changed from Antoine Martin to stdedos

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?

comment:4 Changed 5 weeks ago by Antoine Martin

Owner: changed from stdedos to Antoine Martin
Priority: majorcritical
Status: newassigned

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)

comment:5 in reply to:  2 Changed 5 weeks ago by stdedos

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.

Changed 5 weeks ago by stdedos

Attachment: xpra-2308-compress-draw.zip added

comment:6 in reply to:  4 Changed 5 weeks ago by stdedos

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

comment:7 Changed 5 weeks ago by stdedos

I also have a workaround solution for that: Minimize all other windows.

Then, :0.0 works *perfectly*

comment:8 Changed 5 weeks ago by 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.

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!

comment:9 in reply to:  8 Changed 5 weeks ago by stdedos

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)

comment:10 Changed 5 weeks ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

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.

comment:11 in reply to:  10 Changed 5 weeks ago by stdedos

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 again

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)

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

Note: See TracTickets for help on using tickets.