So I looked at running a standalone app
on one of my distant Linux servers, configured
X and settled on using x2go, plus fluxbox as
a rudimentary lightweight X window manager.

BUT... Despite using a candle chart, where
very little of the chart image changes, it still requires
a huge amount of data transfer to render the
chart. Minimize the chart, and the data transfer
rate plummets.

x2go is supposed to use the nx protocol using
libXcomp.so.3 and I verified that it is using that
lib since it won't start if it can't find it.

So... how come I can't get the famous
"differential X compression"? ...which I interpret
as sending only changed pixel areas across the
net to update the screen?

I just can't figure out why it requires so much
bandwidth when rendering a (mostly) static
chart image using X over the WAN.

I'm trying to avoid splitting my app into a
client-server configuration, and get some reasonable
remote interactive response for the charts. If I
minimize the chart, the data transfer rate drops
to very low levels. Something about the chart,
which is mostly a static image, requires a huge
data transfer, like 0.5 mb / sec.


Any hints?

HyperScalper

There is also a bewilderingly huge list of possible
compression methods:

https://code.x2go.org/doc/x2goserver/man ... ent.8.html
the following is a snippet from that page:

NX COMPRESSION METHODS

As NX compression methods (<link-quality> argument) the following values are possible. The % character must be replaced by a digit 0-9.
nopack, 8, 64, 256, 512, 4k, 32k, 64k, 256k, 2m, 16m 256-rdp, 256-rdp-compressed, 32k-rdp, 32k-rdp-compressed, 64k-rdp 64k-rdp-compressed, 16m-rdp, 16m-rdp-compressed rfb-hextile, rfb-tight, rfb-tight-compressed 8-tight, 64-tight, 256-tight, 512-tight, 4k-tight, 32k-tight 64k-tight, 256k-tight, 2m-tight, 16m-tight 8-jpeg-%, 64-jpeg, 256-jpeg, 512-jpeg, 4k-jpeg, 32k-jpeg 64k-jpeg, 256k-jpeg, 2m-jpeg, 16m-jpeg-% 8-png-jpeg-%, 64-png-jpeg, 256-png-jpeg, 512-png-jpeg, 4k-png-jpeg 32k-png-jpeg, 64k-png-jpeg, 256k-png-jpeg, 2m-png-jpeg, 16m-png-jpeg-% 8-png-%, 64-png, 256-png, 512-png, 4k-png 32k-png, 64k-png, 256k-png, 2m-png, 16m-png-% 16m-rgb-%, 16m-rle-%

Anybody familiar with which ones might fix my issue?
HyperScalper

OK, guys, nx doesn't work

So, installed vnc-server on my CentOS linux
following this guide, and lots of other info
on the net. A bit of firewall config, etc...

https://www.youtube.com/watch?v=gzcPdAksKII

Used ultravns on my Windows PC, and it works
better than anything else I can imagine !!

So do yourselves a favor and don't try to use
X across the WAN !

HyperScalper

I've used xrdp in the past. Performance of chart operations were not a problem at all...

Well, initially I tried to run an X desktop and gnome
on a resource-limited virtual server, and we found that
it was unreliable due to exceeding the resource
max counts.

So we switched to a dedicated Quad Xeon server and
I've been able to run 2 sessions, from 2 separate
linux accounts, and do scalping with tick charts,
all week long.

So simply controlling them through UltraVNC rather than to
try and send X windows operations over the WAN
works very reliably.

Only issue was our dedicated server's time was
1 minute off, so installing ntpd time server fixed
that issue.

Very pleased with performance, and reconnect so
the desktop sessions were continuous. However, some issues
on rendering colors, but fairly minor. Again the window
manager was gnome on CentOS, so other window
managers would differ from my results.

UltraVNC on the Windows side, and TigerVNC on
the CentOS linux side really work well, but beware
that your server is not resource limited in any way
or you will have issues.

HyperScalper