Xpra: Ticket #878: lz4: support HC and fast modes

The mapping should go something like:

Tue, 02 Jun 2015 05:19:50 GMT - Antoine Martin: status changed

The fast modes will have to wait until the please update to r130

These changes are not useful at present: we only ever use the level 9 specified on the command line for the initial hello packet and response, as this is the only "plain" big packet we send, every other "big packets" contain compressed pixels or sound which we compress separately. And for rgb+compress, the level is capped at 5.

When we do add support for "fast", we should update the logic that calculates the compress level for rgb so that we use a slightly higher level. And maybe this would be a good time to try to also honour the compress level specified on the command line: we have logic to dynamically choose the level based on speed, this could be capped or tuned using the command line value.

Thu, 18 Jun 2015 21:48:54 GMT - Antoine Martin:

Sent a pull request for the changes needed to support compress_fast: https://github.com/steeve/python-lz4/issues/36

r9674 allows us to support compress fast if available.

It will be quite difficult to test until the new version is released...

Mon, 06 Jul 2015 10:17:20 GMT - Antoine Martin:

Much better pull request: https://github.com/steeve/python-lz4/pull/41

If nothing happens, I think I will just make a tarball here so we can push it to the beta repo for testing.

Mon, 13 Jul 2015 04:47:25 GMT - Antoine Martin: attachment set

0.8.0.rc1 snapshot

Mon, 13 Jul 2015 05:32:04 GMT - Antoine Martin: owner, status changed

r9910 bumps the build to use the snapshot of the source taken from https://github.com/jonathanunderwood/python-lz4.

The beta area now has python-lz4 0.8.0.rc1 packages for Fedora.

Supporting centos is going to be more difficult: the new package builds against lz4-devel, which is only available in Fedora... EPEL has it, but we don't want to require extra repository dependencies. So we would have to include lz4 in our repo.

And we're not going to bother updating win32 or osx just yet, as they're mostly used as clients and compression speed on the client side is never a bottleneck.

Now, the version stuff looks like this:

>>> import lz4
>>> lz4.LZ4_VERSION
>>> lz4.VERSION
>>> lz4.__version__

r9911 now also checks the underlying liblz4 version (requires r119 or later).

@afarr: ready for testing.

See also #960, r11010.

Wed, 16 Sep 2015 02:17:25 GMT - Antoine Martin: attachment set

quick and dirty patch for building on win32

Fri, 30 Oct 2015 18:55:33 GMT - J. Max Mena:

Apparently we've been using the new version for quite some time now without issue...so I'm gonna go ahead and be confident in saying that it's working.

As for the second point...we're training one of our new employees to start writing Xpra automated test scripts, so we'll get to it "soon" (tm).

Thu, 05 Nov 2015 01:36:16 GMT - alas:

Checking session info with a 0.16.0 r11122 server and client (windows v. fedora21) - it looks like we're using lz4 (level 1).

Is there any point at trying out any of the other levels yet? Is there a flag to try?

Thu, 05 Nov 2015 05:46:46 GMT - Antoine Martin: status changed; resolution set

The levels are chosen automatically based on the speed setting when encoding pixel data. Regular packets should be encoded using the level specified with -z.


Fri, 13 Nov 2015 04:27:43 GMT - Antoine Martin:

Note: for building on win32, someone posted cleaner fixes:

Sun, 02 Oct 2016 05:21:17 GMT - Antoine Martin: attachment set

patch for building latest python-lz4 with msvc

Sat, 23 Jan 2021 05:08:37 GMT - migration script:

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