Xpra: Ticket #471: cursor improvements: send as picture, cache pixels client side

The cursor pixel data is in pre-multiplied argb format. We could encode it with a picture encoder which will be a lot more efficient than lz4/zlib. Also, if the client supports the feature, we could build up a cache of cursor pixels we have sent already and avoid re-sending those again, sending the unique ID of the cursor cache instead. (the cursor cache could be limited to a fixed number of cursor serial numbers to prevent growing too much).

Since cursor changes are fairly rare, the bandwidth savings would be very small - so this is a very low priority ticket.



Wed, 18 Dec 2013 12:14:25 GMT - Antoine Martin: attachment set

adds ability to send cursors compressed with png if client supports it


Wed, 18 Dec 2013 12:23:59 GMT - Antoine Martin: owner, status changed

As the lz4 compression tests were very interesting (see r4925 and ticket:443#comment:4), I thought I would try to compare png and lz4 compression for cursors. Using the png-cursors.patch, and starting an xterm then the "test custom cursor" test script, I found:

So lz4 compresses a lot better than png, and takes half the time to do it! That is just incredibly efficient. This patch will not be merged, and lz4 is likely to be used in places where we currently prefer png (after further tests).


Caching cursors could still be a win, so I am keeping this ticket opened.


Wed, 18 Dec 2013 12:24:37 GMT - Antoine Martin: attachment set

adds ability to send cursors compressed with png if client supports it - records compression timing


Fri, 01 Aug 2014 13:14:43 GMT - Antoine Martin: status changed; resolution set

Recent changes have brought more generic support for compression, including lz4 compression of cursors.

Compressed cursors are already so small that I don't see any point in complicating things with cursor caching.


Sat, 23 Jan 2021 04:56:35 GMT - migration script:

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