[X2Go-User] X2go Connection / compression Settings defunct? Documentation?

[Ulrich Sibiller]

On Mon, Apr 29, 2019 at 3:42 PM Tristan Miller
<psychonaut at nothingisreal.com> wrote:
>
> Dear Nigra,
>
> On Fri, 26 Apr 2019 18:48:34 -0700, Nigra Truo
> <nigratruo at gmail.com> wrote:
> > I'm forced to work with some extreme bandwith restrictions and was
> > looking into using more compression and/or the Modem / ISDN connection
> > setting. (I'm down to old time modem speeds, 128 kbit or less)
> > So far I could not find any documentation that shows what these really
> > do. I normally use the ADSL one, which works. The Modem and ISDN
> > setting seems broken (and has been for as long as I rememeber), they
> > don't really reduce the bandwidth usage nor improve latency.
> > When switching to Modem, the screen updates actually get much worse, I
> > can watch the system update the screen in lines (not the whole screen
> > is updated in one go), which looks like a bug.
> > I have had success setting the image quality to a lower setting, the
> > screen looks worse, which is a good indicator that it is working.
> > I can't find any documentation on what the difference is between
> > different compression methods. Can you point me in the right
> > direction?
> > If I can find the info, I would be up for updating the documentation
> > so that others can find it better.

The code sets tile size and defer parameters depending on the link
speed, but you can also set these parameters on your own, see man
nxagent:

       defer=<int>
               defer image updates (enabled for all connection types
except LAN), accepts values 0, 1 and 2

               The default value can be set via the command line
(-defer). The value provided as nx/nx option is set when resuming a
session, thus it overrides the command line default.

       tile=<string>
               set the tile size in pixels (<W>x<H>) for bitmap data
sent over the wire

               The default value can be set via the command line
(-tile). The value provided as nx/nx option is set when resuming a
session, thus it overrides the command line default.

You can add the desired valued to the X2GO_NXOPTIONS= line in
/etc/x2go/x2goagent.options, e.g. "menu=1,defer=2,tile=128x128"

 * Each defer level adds the following rules to the previous ones:
 *
 * Level 0  Eager encoding.
 *
 * Level 1  No data is put or copied on pixmaps, marking them always
 *          as corrupted and synchronizing them on demand, i.e. when
 *          a copy area to a window is requested, the source is syn-
 *          chronized before copying it.
 *
 * Level 2  The put images over the windows are skipped marking the
 *          destination as corrupted. The same happens for copy area
 *          and composite operations, spreading the corrupted regions
 *          of involved drawables.

Here are the defaults as found in the code:

    case LINK_TYPE_MODEM:
      deferLevel = 2;
      tileWidth  = 64;
      tileHeight = 64;
    case LINK_TYPE_ISDN:
      deferLevel = 2;
      tileWidth  = 64;
      tileHeight = 64;
    case LINK_TYPE_ADSL:
      deferLevel = 2;
      tileWidth  = 4096;
      tileHeight = 4096;
    case LINK_TYPE_WAN:
      deferLevel = 1;
      tileWidth  = 4096;
      tileHeight = 4096;
    case LINK_TYPE_NONE:
    case LINK_TYPE_LAN:
      deferLevel = 0;
      tileWidth  = 4096;
      tileHeight = 4096;
    default:
      deferLevel = 0;
      tileWidth  = 64;
      tileHeight = 64;

To my surprise I found another parameter today which is currently
undocumented: -irlimit <kB/s>. This will limit the amount of data that
is used to update drawables on the real display. It can only be passed
via command line. To play with it add it to
/etc/x2go/x2goagent.options.

> I asked pretty much the same question here in 2017.  The only response
> I got was from another user who, like you and me, was only able to make
> a few observations by trial and error testing:
> <http://lists.x2go.org/pipermail/x2go-user/2017-February/004254.html>
>
> I agree that it would be nice to get a comprehensive overview of the
> different settings.

Well, I have done some research tonight:

First it is worth noting that what we are talking about here is the
way NX will compress images travelling the wire. NX also (delta)
compresses the message format that X11 uses. This is unaffected by the
pack method setting. So if you only have an xterm handling some text
you probalby do not see much difference after changing the pack method
because there are not many images involved. Also note that NX uses a
cache so image compression will help in low bandwidth situations, but
maybe less than expected. That's because once the image has travelled
the wire it will be cached on the other side and not travel the wire
again.

x2goclient has three command line options that will influence the compression:

       --link Set default link type (modem,isdn,adsl,wan or lan, default: adsl).

       --pack Set default pack method (default: '16m-jpeg').

       --quality
              Set default image quality(0-9, default: 9).

These can also be set in the Connection tab of the chosen session.

The values you use for these parameter are passed down to the nx
software. Some of the parameters there are described in "man nxproxy"
as follows:

       link=<string>
               An indication of the link speed that is going to be
used between the proxies. Usually the compression and the other link
parameters depend on this setting. The value can be either 'modem',
               'isdn', 'adsl', 'wan', 'lan', 'local' or a bandwidth
specification, like for example '56k', '1m', '100m', etc.
       data=<int>
               Enable or disable the ZLIB data compression. It is
possible to specify a value between 0 and 9. Usually the value is
chosen automatically based on the requested link setting.
       stream=<int>
               Enable or disable the ZLIB stream compression. The
value, between 0 and 9, is usually determined according to the
requested link setting. Not fully implemented in nx-X11 Agent, yet.
       pack=<string>
               Determine the method used to compress images.

Now, the pack and quality settings define the compression algorithm
and the quality of the compressed images. In general there are several
groups of compression methods. Most of them will use a user-provided
number of colors from 8 to 16m. Generic form:
<number-of-colors>[-<method>[-<quality>]]
- none (no image compression, lossless)
- masked (reduce number of bits per pixel, lossy): Format of the pack
parameter: "<number of colors>", e.g "16m"
- jpeg (jpeg compression, lossy): <number of colors>-jpeg, e.g. "16m-jpeg"
- png (png compression, lossy): <number of colors>-png, e.g. "4k-png"
- rgb (zlib compression with Z_DEFAULT_STRATEGY, lossless) : "rgb" or
"16ḿ-rgb" /(16m is the only number of colors supported)
- Run Length Encoding (zlib compression with Z_RLE strategy,
lossless): "rle" or "16m-rle" (16m is the only number of colors
supported)
- bitmap (remove each 4th byte, lossless): "bitmap" or "16m-bitmap"
(16m is the only number of colors supported)

For the lossy compressors the string can also have a "-<quality>"
suffix. This suffix will define the pack quality. The default is "9".

There are some hig level compression modes, too, that will map to one
from the list above:
- "lossy" will map to "16m-jpeg"
- "lossless" will map to "16m-rle-9" for link=lan and "16m-bitmap" for
all other link types.
- "adaptive" will choose lossy or lossless, depending on the
characteristics of the image

If no pack method is provided it will be set automatically from the
link parameter:
- modem: adaptive-3
- isdn: adaptive-5
- adsl: adaptive-7
- wan: adaptive-9
- lan: adaptive-9

Images, that have a width or height of 2 or less pixels or are not
bigger than 512 bytes will not be compressed (but they are still
cached).

Hope this helps,

Uli