#1460 closed defect (fixed)
Paint bug with latest trunk (r15230)
Reported by: | J. Max Mena | Owned by: | J. Max Mena |
---|---|---|---|
Priority: | critical | Milestone: | 2.0 |
Component: | server | Version: | trunk |
Keywords: | Cc: |
Description
Testing with a Fedora 25 client and server using Trunk 2.X r15230:
- Navigating to Google Maps using Chrome and moving the map around causes Chrome to stop updating paints properly, and the logs print out this error:
2017-03-07 15:02:05,593 Error during scrolling detection 2017-03-07 15:02:05,593 with image=XShmImageWrapper(BGRX: 5, 81, 1106, 750), options={'scroll': True} Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py", line 1631, in do_video_encode return self.encode_scrolling(scroll_data, image, options) File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py", line 1502, in encode_scrolling sub = image.get_sub_image(0, sy, w, sh) File "xpra/x11/bindings/ximage.pyx", line 371, in xpra.x11.bindings.ximage.XImageWrapper.get_sub_image (xpra/x11/bindings/ximage.c:4276) Exception: invalid sub-image height: 0+836 greater than image height 750
Attachments (4)
Change History (14)
Changed 5 years ago by
Attachment: | 1460paintbug.png added |
---|
comment:1 Changed 5 years ago by
Changed 5 years ago by
Attachment: | 1460info.txt added |
---|
Xpra info with the stuck window. (Window is the one titled Hanover, 71)
comment:2 Changed 5 years ago by
Owner: | changed from Antoine Martin to J. Max Mena |
---|
Running with "-d scroll" quickly uncovered the problem:
encode_scrolling(XShmImageWrapper(BGRX: 7, 105, 2282, 1774), {'scroll': True}) window-dimensions=(2294, 1879) too many items: 2 scrolls, 38 non-scrolls - sending just one image instead will send scroll data={}, non-scroll={0: 1879} Error during scrolling detection with image=XShmImageWrapper(BGRX: 7, 105, 2282, 1774), options={'scroll': True} Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py", line 1631, in do_video_encode return self.encode_scrolling(scroll_data, image, options) File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py", line 1502, in encode_scrolling sub = image.get_sub_image(0, sy, w, sh) File "xpra/x11/bindings/ximage.pyx", line 371, in xpra.x11.bindings.ximage.XImageWrapper.get_sub_image (xpra/x11/bindings/ximage.c:4276) Exception: invalid sub-image height: 0+1879 greater than image height 1774
When we hit "too many items", we were using the wrong dimensions.
Fixed in r15231 - which also makes the whole thing more robust.
comment:3 Changed 5 years ago by
Upped server and client to r15267:
I no longer see the error but I'm still not getting the paint updates client-side. I know the server is doing the calculations proper and there are client-side paints going on (XPRA_OPENGL_PAINT_BOX=1
, but I'm not seeing the paints properly. (Will attach a screenshot)
It seems to only be for the maps tab so I suspect this is an issue with my Chrome install. I'll try and investigate in the next hour while I'm still home until I leave. I'll follow up on Tuesday (California time).
comment:4 Changed 5 years ago by
Milestone: | → 2.0 |
---|---|
Priority: | major → critical |
Is this still an issue? (works fine here on Fedora 25)
comment:5 Changed 5 years ago by
Yes I still don't see any paints whatsoever in Chrome, but only on the Maps page. I'm not sure if this is an issue anyone else is seeing or maybe it's just my work machine.
comment:6 Changed 5 years ago by
Try to:
- downgrade to v0.17.x (or 0.14.x even) - does it still occur?
- compare with another system, ie: try it in a VM
- try with vglrun in case maps using opengl rendering
- try with opengl rendering on / off
- try taking a screenshot "xpra screenshot"
- try with "sync-xvfb" enabled and take a screenshot of the backing display (using "scrot" or other screencapture commands)
etc..
Changed 5 years ago by
Attachment: | Chrome Paint Bug Local.png added |
---|
comment:7 Changed 5 years ago by
Okay I'm convinced now that this is an issue with Chrome on Fedora - I've reproduced it on Pandora on my local Chrome running directly on my Workstation.
I'll try what you mentioned as well today.
comment:8 Changed 5 years ago by
Okay, I tried downgrading to Xpra 1.X and I still got the same issue, so it's not 2.0
- Running with VGLRun doesn't change anything
- Opengl rendering on/off doesn't change anything
I'll try doing a screenshot Thursday as I've run out of time today.
comment:9 Changed 5 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Okay I've tried this on three other machines now (all Fedora), and the issue is limited to just one single machine. I am entirely convinced at this point that the issue isn't with Xpra, but rather my Chrome install on that machine.
I'm gonna go ahead and close this ticket now.
comment:10 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1460
The screenshot I attached is of what I'm seeing in Chrome (with the
--show-paint-rects
flag).