xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 5 years ago

#700 closed defect (fixed)

CentOS 6.4 client is often rendering large portions of window in black

Reported by: alas Owned by: alas
Priority: critical Milestone:
Component: client Version: 0.14.x
Keywords: Cc:

Description

With CentOS 0.14.3 client, scrolling sometimes causes various portions of the screens to render as plain black. It looks like it might be a very slow auto_refresh which renders in black until the refresh is complete.

Attaching a screen shot, will try to get more info (I think I noticed that it is trying to use webp encoding, but will have to confirm).

Attachments (1)

CentOS-black-screen-portions.png (16.5 KB) - added by alas 5 years ago.
ticket700 web page refreshes render most of page, aside from some widgets, in black

Download all attachments as: .zip

Change History (9)

Changed 5 years ago by alas

ticket700 web page refreshes render most of page, aside from some widgets, in black

comment:1 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas

Inlining the screenshot:
ticket700 web page refreshes render most of page, aside from some widgets, in black

Usual questions:

  • switch encoding
  • opengl on/off
  • xpra info (captured whilst screen has black)

etc..
Also: 0.14.3 has bugs, try with 0.14.7 first.

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

comment:2 Changed 5 years ago by Antoine Martin

Also, server-side -d encoding output might help, xpra info, etc.

comment:3 Changed 5 years ago by alas

Could be related to issues in #717 (webp and/or OpenGL issues)... should test with 0.14.12 webp fixes to see if it works without OpenGL as well as with.

comment:4 Changed 5 years ago by Antoine Martin

Bump. Can I close this or is this reproducible?

comment:5 Changed 5 years ago by alas

Well... it's reproducible, but watching the server side (our fedora 20 trunk build) while connecting with your new trunk beta CentOS 6.4 build, I see that it is probably our fedora server build:

2014-12-12 12:51:38,546 error processing damage data: invalid webp configuration!
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/server/source.py", line 1586, in encode_loop
    fn_and_args[0](*fn_and_args[1:])
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1128, in make_data_packet_cb
    packet = self.make_data_packet(damage_time, process_damage_time, wid, image, coding, sequence, options)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1434, in make_data_packet
    ret = encoder(coding, image, options)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1485, in webp_encode
    return webp_encode(coding, image, self.rgb_formats, self.supports_transparency, q, s, options)
  File "/usr/lib64/python2.7/site-packages/xpra/server/picture_encode.py", line 62, in webp_encode
    cdata = enc_webp.compress(image.get_pixels(), w, h, stride=stride/4, quality=quality, speed=speed, has_alpha=alpha)
  File "xpra/codecs/webp/encode.pyx", line 336, in xpra.codecs.webp.encode.compress (xpra/codecs/webp/encode.c:1850)
Exception: invalid webp configuration!

I suppose we can close this (I am also finding a reproducible seg fault when opengl is on, which I will open another ticket for).

comment:6 Changed 5 years ago by Antoine Martin

r8244 added some self tests to webp and vpx encoders, so we won't end up using them if the libraries installed don't match the versions the code was built against. You should get a warning in the log instead.

Please close or provide more details so that I can reproduce.

comment:7 Changed 5 years ago by Antoine Martin

Priority: majorcritical

(raising - should be closed I think)

comment:8 Changed 5 years ago by alas

Resolution: fixed
Status: newclosed

Testing with the new beta build client 0.15.0 runknown, against fedora 20 server 0.15.0 r8661 ... I can't reproduce this anymore - not even when I specify encodings and exclude webp.

  • Note, we are seeing this with some fedora 19 clients with very old libraries, using AMD video cards... beginning to suspect it might be a matter of old/clashing open source video card libraries... closing this ticket, but if we discover anything related to video libraries we'll post it in this ticket, or open a new ticket, as seems appropriate.
Note: See TracTickets for help on using tickets.