Xpra: Ticket #521: broken tray icons

Noticed with 0.11.3: application's tray icons are corrupted -- they appear with coloured vertical stripes. It happens only with some encodings, notably with "PNG (8bpp colour)". The following errors appear in client log:

2014-02-18 14:38:26,788 error processing draw packet
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/xpra/client/ui_client_base.py", line 1509, in _draw_thread_loop
    self._do_draw(packet)
  File "/usr/lib/python2.7/dist-packages/xpra/client/ui_client_base.py", line 1557, in _do_draw
    window.draw_region(x, y, width, height, coding, data, rowstride, packet_sequence, options, [record_decode_time])
  File "/usr/lib/python2.7/dist-packages/xpra/client/client_tray.py", line 105, in draw_region
    assert coding in ("rgb24", "rgb32", "png", "mmap", "webp"), "invalid encoding for tray data: %s" % coding
AssertionError: invalid encoding for tray data: png/P

RAW/RGB_zlib is also exhibiting this problem although without logging any errors.

Icons look OK with H.264 so to reproduce the problem it may be necessary to override default encoding on attach.



Tue, 18 Feb 2014 03:47:15 GMT - Antoine Martin: owner, status changed; milestone set

Thanks, we should never send the tray icons as png/P or png/L: those encodings save space by subsampling colours, but since tray icons are small this doesn't save anything at all, in fact in some cases it may even make things bigger (adding the palette to the pixel data).

Could well be related to #500


Tue, 18 Feb 2014 04:49:19 GMT - onlyjob:

I forgotten to add that it looks like tray icons might get broken in 0.11.3 (at least with RAW/RGB+zlib encoding). It is a regression as I don't remember anything like this in 0.11.2 and earlier...


Fri, 28 Feb 2014 10:04:06 GMT - Antoine Martin:

First, I will probably have to cherry pick some fixes for v0.11 from ticket:500#comment:11.


I can reproduce the bug, r5628 will need to be backported and fixes png/P and png/L support for the system tray: if the server wants to use this encoding, let it!

We should pick a better encoding, but that's a different issue.

What is odd is that everything looks correct in the logs:

As I expected, the PNG compression ends up being worse than lz4! (604 bytes vs 468 bytes)


Fri, 28 Feb 2014 10:38:44 GMT - Antoine Martin:

I was wrong in the comment above, there is something wrong: the rgb_format says RGB even though this is rgb32 with alpha... On the server side, I see:

rgb_encode(rgb32, XImageWrapper(BGRA: 0, 0, 64, 64), {}) rgb_formats=['RGB']
rgb_reformat(XImageWrapper(RGB: 0, 0, 64, 64)) converted from BGRA (16384 bytes) to RGB (12288 bytes) in 0.1ms, rowstride=192

Fixes:

Still TODO:

Note: this bug has been present for a long time, the only thing that changed is that we are now more likely to use rgb for the tray (and rightly so since it takes up less space and much less effort)


Fri, 28 Feb 2014 11:55:20 GMT - Antoine Martin: owner, status changed

Totally non-trivial backport of seemingly innocuous r5624 in r5634: this has a small side effect: a change in how encoding statistics are recorded... More than I would like for a stable change, but better than keeping the old bug in. And maybe I should have backported the whole of r5605..

Please test and close so I can release 0.11.4, thanks!


Mon, 03 Mar 2014 02:49:43 GMT - onlyjob: owner changed

Tested v0.11.x@5643, works great. Thank you.


Mon, 03 Mar 2014 03:26:30 GMT - Antoine Martin: status changed; resolution set


Sat, 23 Jan 2021 04:58:14 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/521