xpra icon
Bug tracker and wiki

Opened 3 years ago

Closed 3 years ago

#1287 closed defect (fixed)

desktop-scaling triggering expire_delayed_region traceback

Reported by: alas Owned by: alas
Priority: major Milestone: 1.0
Component: server Version: trunk
Keywords: Cc:

Description

Using a 1.0 r13101 win32 client & 1.0 r13401 (unknown changes) fedora 23 server, when I initially connect, I get the following client display size info from the server:

2016-08-19 12:19:45,631  client root window size is 3072x1296 with 1 display:
2016-08-19 12:19:45,631   Default (1354x571 mm - DPI: 57x57) workarea: 3072x1272
2016-08-19 12:19:45,631     DISPLAY1 2304x1296 at 768x0 (621x341 mm - DPI: 94x96) workarea: 2304x1272
2016-08-19 12:19:45,632     DISPLAY2 768x432 (597x336 mm - DPI: 32x32) workarea: 768x383
2016-08-19 12:19:45,651 server virtual display now set to 3904x1440 (best match for 3072x1296)

And the following client side:

2016-08-19 12:19:44,237  desktop size is 5120x2160 with 1 screen:
2016-08-19 12:19:44,239   Default (1354x571 mm - DPI: 96x96) workarea: 5120x2120
2016-08-19 12:19:44,239     DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 3840x2120
2016-08-19 12:19:44,239     DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 1280x638
2016-08-19 12:19:44,240  upscaled by 167%, virtual screen size: 3072x1296
2016-08-19 12:19:44,240   Default (1354x571 mm - DPI: 57x57) workarea: 3072x1272
2016-08-19 12:19:44,240     DISPLAY1 2304x1296 at 768x0 (621x341 mm - DPI: 94x96) workarea: 2304x1272
2016-08-19 12:19:44,240     DISPLAY2 768x432 (597x336 mm - DPI: 32x32) workarea: 768x383

Using keyboard shortcuts to reduce desktop-scaling, reducing to 150% seems to work fine, but when reducing to 125% (not doing so particularly quickly), I'm seeing tracebacks (just using an xterm to launch chrome, with a lawn gnome image page open: http://www.fandomplanet.com/mm5/graphics/00000001/butcher-lawn-gnome-20__57275.jpg):

2016-08-19 12:05:45,284 client display size is 4096x1728 with 1 screen:
2016-08-19 12:05:45,285   Default (1354x571 mm - DPI: 76x76) workarea: 4096x1696
2016-08-19 12:05:45,285     DISPLAY1 3072x1728 at 1024x0 (621x341 mm - DPI: 125x128) workarea: 3072x1696
2016-08-19 12:05:45,285     DISPLAY2 1024x576 (597x336 mm - DPI: 43x43) workarea: 1024x510
2016-08-19 12:05:45,302 DPI set to 77 x 77
2016-08-19 12:05:45,326 sent updated screen size to 1 client: 4096x2160 (max 8192x4096)
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1139, in expire_delayed_region
    self.may_send_delayed()
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1239, in may_send_delayed
    self.do_send_delayed()
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1251, in do_send_delayed
    self.send_delayed_regions(*delayed)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1267, in send_delayed_regions
    self.do_send_delayed_regions(damage_time, regions, coding, options)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py", line 632, in do_send_delayed_regions
    self.process_damage_region(damage_time, actual_vr.x, actual_vr.y, actual_vr.width, actual_vr.height, coding, video_options, 0)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py", line 735, in process_damage_region
    sub = image.get_sub_image(w-dw, 0, dw, h)
  File "xpra/x11/bindings/ximage.pyx", line 304, in xpra.x11.bindings.ximage.XImageWrapper.get_sub_image (xpra/x11/bindings/ximage.c:3398)
Exception: invalid sub-image width: 1122+1 greater than image width 1122
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1139, in expire_delayed_region
    self.may_send_delayed()
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1239, in may_send_delayed
    self.do_send_delayed()
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1251, in do_send_delayed
    self.send_delayed_regions(*delayed)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1267, in send_delayed_regions
    self.do_send_delayed_regions(damage_time, regions, coding, options)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py", line 632, in do_send_delayed_regions
    self.process_damage_region(damage_time, actual_vr.x, actual_vr.y, actual_vr.width, actual_vr.height, coding, video_options, 0)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py", line 735, in process_damage_region
    sub = image.get_sub_image(w-dw, 0, dw, h)
  File "xpra/x11/bindings/ximage.pyx", line 304, in xpra.x11.bindings.ximage.XImageWrapper.get_sub_image (xpra/x11/bindings/ximage.c:3398)
Exception: invalid sub-image width: 1122+1 greater than image width 1122
2016-08-19 12:11:22,947 get_mimetype()=['application/pdf', 'application/postscript']

Regularly reproducible (though sometimes not until scaled down to 100% rather than at the 125% I hit the traceback the first three tries) with that gnome page loaded, takes a little more work (scaling up and down) with just google-chrome start page... couldn't repro with an xterm only.

Change History (3)

comment:1 Changed 3 years ago by Antoine Martin

Status: newassigned

Similar to #1237

comment:2 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

I couldn't reproduce this, despite using:

XPRA_BATCH_ALWAYS=1 XPRA_BATCH_MIN_DELAY=100 xpra start ...

To force the use of a batch delay, which will ensure we go through "expire_delayed_region". I then also make sure we end up using a video encoder.
But no luck: I cannot hit this bug.

  • r13812 adds some sanity checks in "do_send_delayed_regions" to detect when the window is now smaller than the video region - I don't think this is what's causing the problem here, but cheap to add
  • r13813 + r13814: is more likely to be the correct fix: we re-read the image dimensions after capturing it as it may have been clipped to the new window size

@afarr: does that help? if not, can you give me steps to reproduce reliably?

Last edited 3 years ago by Antoine Martin (previous) (diff)

comment:3 Changed 3 years ago by alas

Resolution: fixed
Status: newclosed

It looks like the issue was "intimately" related to the versions mentioned above... and may have required the somewhat peculiar desktop layout I have on my windows 8.1 machine (4K display and 1440p display with hdmi connection turning it into a 1280x720 display...).

I had to revert to the precise versions mentioned in the ticket to repro at all. Even leaving the (re-)installed win32 1.0 r13101 client and testing against a newly built 1.0 r13828 server, I am totally incapable of repro'ing.

I'm going to go ahead and close... presuming that the fixes you've made will improve on the general changes which themselves seemed to have fixed whatever it was I was able to trigger with that specific combo of server and client.

Note: See TracTickets for help on using tickets.