---------- Forwarded message ---------
From: Ulrich Sibiller <uli42(a)gmx.de>
Date: Sun, May 31, 2020 at 10:58 PM
Subject: Re: [ArcticaProject/nx-libs] Document compression (#802)
To: ArcticaProject/nx-libs
<reply+ABQHBZHBGIOEJSNWVCG4BAV4372CLEVBNHHBUM3YJI(a)reply.github.com>
Cc: ArcticaProject/nx-libs <nx-libs(a)noreply.github.com>, Author
<author(a)noreply.github.com>
"nopack" in x2go becomes "none" in NX. And it means exactly what it
says: do not compress images. This setting saves CPU cycles but
required more bandwidth. Images are normally cached this so this is
relevant only for the tiem an image must be transferred to the other
side.
All the things I documented are valid for plain NX sessions (without
using x2go but other software). In NX - if you don't specify a
compression method explicitly but only a link type - the compression
method is derived from the link type. For ADSL you correctly expect
adaptive-7 as I listed in the document.
Using x2go things are a bit different. The NX code is the same and so
are the built-in defaults. For ADSL this is still "adaptive-7". But
x2go does always provide a compression type in addition to the link
type. So that default is never used but overridden by the compression
settings the user specifies in x2go's session configuration. So
regarding compression you always get what you select there, in your
case it is "nopack" (which becomes "none" at some point because of the
internal naming of the parameter).
In other words: in x2go you always have to select a clever combination
of link speed and compression while using plain NX you can stick with
the link speed and use the defaults.
If you only touch the link speed setting you will always get 16m-jpeg.
I am using an own software for connection (which I cannot make public
for legal reasons) and always stick with the defaults. I was not aware
of this x2go behaviour. But this might explain why I don't see the
performance problems I sometimes hear about from other people.
So I consider this a bug.
Developers: what's your opinion about this?
Uli
On Sun, May 31, 2020 at 10:27 PM Anton Driesse <notifications(a)github.com> wrote:
>
> Sorry, you lost me.
>
> I think you're saying nopack is the same as "no pack", but did you say what nopack really is?
>
> Anyway, using nopack I do observe that the choice of link makes a difference.
>
> ADSL gave me reasonable update speed and quality;
> with MODEM I expected quick update and poor quality, but I got slow update and poor quality;
> with LAN I expected and got slow update but high quality.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub, or unsubscribe.
