>>>>> On 2023-06-12, Andreas Kohlbach wrote:
>>>>> On Sun, 11 Jun 2023 16:16:58 -0400, David W. Hodgins wrote:

[Cross-posting to news:comp.windows.x.]

>> For computers accessed over the internet, I use ssh with X
>> forwarding, and within my lan where I want the program running
>> on one computer with the gui displayed on another.

> You could also use VNC or RDP. But I suppose SSH has the least
> overhead, thus is fastest.

I think it conflates 'transport' and 'application' protocols.

As is pointed elsewhere in this thread, you can use X over
TCP, which will have even less overhead than X over SSH.

OTOH, it's certainly possible to use VNC over SSH (whether
via port forwarding, or as described in Debian Bug#1018240,
though there're some fixes pending to the recipe), which
will have more overhead than VNC over (unencrypted) TCP,
yet possibly /less/ than X over SSH.

http://bugs.debian.org/1018240

Now, I don't have any measurements to back this claim, but
note that while /classic/ X software sends short commands
to the X server (draw a line here, render a string there),
/modern/ software mostly just pushes pre-rendered pixmaps
to the server. There, VNC protocol may have an advantage,
as it's pretty much dedicated to shoving image data around,
and does not support requests such as drawing polygons on
the server, which modern software won't use anyway.

To summarize, if you mostly want to use classic, libXt- or
libX11- based software, like, say, xedit, vtwm, xterm (though
note that at least xterm /can/ be configured to render text
on the client), use X over SSH. (Unless SSH overhead becomes
critical /and/ the communication is secured in some other manner.)

If you mostly want to use modern software (Darktable, Chromium,
Libreoffice, Merkaartor, that sort of thing) it's worth trying
VNC, which may happen to have less overhead in this case.

PS. Reading http://bugs.debian.org/947713 recently made me wonder,
yet again, if opting for a modern GUI toolkit for your
software is a perfectly valid choice, provided you're willing
to rewrite it from scratch every decade or so. (Conversely,
I don't suppose libXaw API has had major incompatible changes
since at least early 1990s?)

--
FSF associate member #7257 http://am-1.org/~ivan/

Ivan Shmakov <ivan@siamics.netNOSPAM.invalid> writes:

> Now, I don't have any measurements to back this claim, but
> note that while /classic/ X software sends short commands
> to the X server (draw a line here, render a string there),
> /modern/ software mostly just pushes pre-rendered pixmaps

This is untrue. The GTK toolkit uses Cairo, which utilizes the X
rendering extension to composite trapezoids, glyphs and pictures.
Little if any rendering is done by the client itself.

> to the server. There, VNC protocol may have an advantage,
> as it's pretty much dedicated to shoving image data around,
> and does not support requests such as drawing polygons on
> the server, which modern software won't use anyway.

Only if you're using software that uses direct GL rendering. Most
software (both Qt and GTK+) makes ample use of the X rendering
extension.

> If you mostly want to use modern software (Darktable, Chromium,
> Libreoffice, Merkaartor, that sort of thing) it's worth trying
> VNC, which may happen to have less overhead in this case.

I don't know what Merkaartor is, but both Darktable (Qt) and Libreoffice
will use the X rendering extension.

>>>>> On 2023-06-13, Po Lu wrote:
>>>>> Ivan Shmakov writes:

>> Now, I don't have any measurements to back this claim, but note
>> that while /classic/ X software sends short commands to the X
>> server (draw a line here, render a string there), /modern/
>> software mostly just pushes pre-rendered pixmaps to the server.

> This is untrue. The GTK toolkit uses Cairo, which utilizes the X
> rendering extension to composite trapezoids, glyphs and pictures.
> Little if any rendering is done by the client itself.

While I'm aware of the /existence/ of Xrender, I admit I know
virtually nothing as to what extent it's actually used, and
especially how much network traffic its use saves, as compared
to classic X facilities, X pixmaps, and VNC. My experience,
however, so far has been that modern X applications tend to be
more 'responsive' when used over VNC.

Do you have any suggestions on how to measure the network traffic
involved for those cases?

I suppose that aside of corner cases, the X11 requests like
PolyText8 will still use the least amount of network traffic
to display a given string, no?

>> There, VNC protocol may have an advantage, as it's pretty much
>> dedicated to shoving image data around, and does not support
>> requests such as drawing polygons on the server, which modern
>> software won't use anyway.

> Only if you're using software that uses direct GL rendering.

As using GL either requires proprietary software (there /are/
exceptions, but they're regrettably few and far between), or
results in unusably low performance (with Mesa, and aside of
the most trivial of applications), I mostly avoid GL and
applications that require it.

> Most software (both Qt and GTK+) makes ample use of the X rendering
> extension.

I gather such software also falls back to some other means when
the extension is not available?

I've just checked and it appears that TightVNC that I run modern
X applications over doesn't support Xrender:

$ xdpyinfo
....
number of extensions: 7
BIG-REQUESTS
MIT-SHM
MIT-SUNDRY-NONSTANDARD
SHAPE
SYNC
XC-MISC
XTEST

Despite of this, I don't seem to have any issues with said
applications.

I've also tried $ xterm -fa "Bitstream Vera Sans Mono", which
works without issue there; and $ xclock -render, which appears
to fall back to -norender.

>> If you mostly want to use modern software (Darktable, Chromium,
>> Libreoffice, Merkaartor, that sort of thing) it's worth trying
>> VNC, which may happen to have less overhead in this case.

> I don't know what Merkaartor is,

A Qt-based OpenStreetMap editor. I'm not particularly happy
with it, but until I can have something better (I'd rather
prefer Tk, or at least wxWidgets), it works. Mostly.

> but both Darktable (Qt) and Libreoffice will use the X rendering
> extension.

Given that the bulk of network traffic generated by Darktable
is typically pieces of photographs, I don't think Xrender makes
much difference overall.

--
FSF associate member #7257 np. Sign by Paolo Pavan

Ivan Shmakov <ivan@siamics.netNOSPAM.invalid> writes:

> While I'm aware of the /existence/ of Xrender, I admit I know
> virtually nothing as to what extent it's actually used, and
> especially how much network traffic its use saves, as compared
> to classic X facilities, X pixmaps, and VNC. My experience,
> however, so far has been that modern X applications tend to be
> more 'responsive' when used over VNC.

The rendering extension exists because the X protocol itself doesn't
provide alpha compositing capabilities, complex transforms and filters,
or anti-aliased polygon rendering. If your program has no use for such
facilities, it has no use for XRender, but most newer X clients do.

I can't explain your experience, but I suspect it's due to round-trip
latency, not to the network traffic used by drawing requests.

> Do you have any suggestions on how to measure the network traffic
> involved for those cases?

Not really, sorry.

> I suppose that aside of corner cases, the X11 requests like
> PolyText8 will still use the least amount of network traffic
> to display a given string, no?

I suspect that RenderCompositeGlyphs8 and RenderCompositeGlyphs16 have
comparable network traffic requirements to PolyText8/16. Glyphs are
only transferred to the server once, when the font is opened by the
client; references to them use numeric IDs assigned by the
RenderAddGlyphs request.

> I gather such software also falls back to some other means when
> the extension is not available?

GTK+, which uses Cairo, will. Judging from what you have said, Qt does
as well.

> I've just checked and it appears that TightVNC that I run modern
> X applications over doesn't support Xrender:
>
> $ xdpyinfo
> ...
> number of extensions: 7
> BIG-REQUESTS
> MIT-SHM
> MIT-SUNDRY-NONSTANDARD
> SHAPE
> SYNC
> XC-MISC
> XTEST
>
> Despite of this, I don't seem to have any issues with said
> applications.
>
> I've also tried $ xterm -fa "Bitstream Vera Sans Mono", which
> works without issue there; and $ xclock -render, which appears
> to fall back to -norender.

Cairo will fall back to the X core protocol if Render is not supported.
I'm afraid I don't know how it uses the core protocol, but it will be
slower, as compositing and anti-aliasing will be done client-side.

xclock -norender won't perform anti-aliasing.

> A Qt-based OpenStreetMap editor. I'm not particularly happy
> with it, but until I can have something better (I'd rather
> prefer Tk, or at least wxWidgets), it works. Mostly.

This should use XRender, yes.

> Given that the bulk of network traffic generated by Darktable
> is typically pieces of photographs, I don't think Xrender makes
> much difference overall.

Those will pose problems, yes.

If I got the attributions right,
Ivan Shmakov <ivan@siamics.netNOSPAM.invalid> asked:
> Do you have any suggestions on how to measure the network traffic
> involved for those cases?

Have a look at netstat and iostat.

Of course, if you're doing the monitoring in an X window, the act of
moving the mouse between windows, typing commands, etc. will also cause
a bunch of X events, so you'd want to use the "repeat every N seconds"
features of those commands.

There's also tcpdump, but that's likely a lot more work to extract
the numbers you want.

I haven't actually tried these, and they might only work if the network
traffic actually goes to what appears to be a remote host.

HTH,
-WBE

Ivan Shmakov <ivan@siamics.netnospam.invalid> wrote:
>>>>>> On 2023-06-13, Po Lu wrote:
>>>>>> Ivan Shmakov writes:
>
> >> Now, I don't have any measurements to back this claim, but note
> >> that while /classic/ X software sends short commands to the X
> >> server (draw a line here, render a string there), /modern/
> >> software mostly just pushes pre-rendered pixmaps to the server.
>
> > This is untrue. The GTK toolkit uses Cairo, which utilizes the X
> > rendering extension to composite trapezoids, glyphs and pictures.
> > Little if any rendering is done by the client itself.
>
> While I'm aware of the /existence/ of Xrender, I admit I know
> virtually nothing as to what extent it's actually used, and
> especially how much network traffic its use saves, as compared
> to classic X facilities, X pixmaps, and VNC. My experience,
> however, so far has been that modern X applications tend to be
> more 'responsive' when used over VNC.

NX apparantly uses caching as well as compression to reduce network
lattency with X.

> Do you have any suggestions on how to measure the network traffic
> involved for those cases?

There's Xscope.

https://gitlab.freedesktop.org/xorg/app/xscope
(webpage requires Javascript, grr..)

ftp://x.org/pub/individual/app/xscope-1.4.4.tar.xz

--
__ __
#_ < |\| |< _#

>>>>> On 2023-06-23, Po Lu wrote:
>>>>> Ivan Shmakov writes:

>> My experience, however, so far has been that modern X applications
>> tend to be more 'responsive' when used over VNC.

> The rendering extension exists because the X protocol itself doesn't
> provide alpha compositing capabilities, complex transforms and filters,
> or anti-aliased polygon rendering. If your program has no use for such
> facilities, it has no use for XRender, but most newer X clients do.

I can't readily think of a good reason one of /my/ programs
might find these facilities handy, but /everyone's/ software
nowadays is apparently being developed with the assumption
those are a must, so even though I don't /directly/ benefit
from them, it's still something I have to deal with at times.

> I can't explain your experience, but I suspect it's due to round-trip
> latency, not to the network traffic used by drawing requests.

I don't see why it might differ between VNC and X, but it's been
some time since I've last been using X over SSH (to any extent),
so I might be forgetting some important details.

>> Do you have any suggestions on how to measure the network traffic
>> involved for those cases?

> Not really, sorry.

FWIW, OpenSSH ssh(1) client reports the numbers when used with
-v; I suppose I can try comparing them later.

$ ssh -nv -- giaph cal
....
Transferred: sent 3440, received 2104 bytes, in 0.0 seconds
....
$

Debian has xtrace(1), which (with -w) reports sizes of individual
requests and responses, but not the sums. There's xtruss in
pkgsrc (NetBSD) as well, which I haven't yet tried.

For now, however, I've decided to go with plain old strace(1).

http://manpages.debian.org/bookworm/xtrace.1
http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/x11/xtruss/
http://manpages.debian.org/bookworm/strace.1

>> I suppose that aside of corner cases, the X11 requests like
>> PolyText8 will still use the least amount of network traffic to
>> display a given string, no?

> I suspect that RenderCompositeGlyphs8 and RenderCompositeGlyphs16
> have comparable network traffic requirements to PolyText8/16.
> Glyphs are only transferred to the server once, when the font is
> opened by the client; references to them use numeric IDs assigned
> by the RenderAddGlyphs request.

So, I'm going to use two Xvfb(1) X servers (one with Xrender,
the other without) and three Xterms: two configured to use
Freetype fonts (with and without Xrender), and one more to use
an -iso10646-1 X one. (As an aside, -hold does little good in
this specific test, except for allowing for xwininfo.)

$ Xvfb :29 +extension RENDER -listen unix -retro -noreset &
$ Xvfb :31 -extension RENDER -listen unix -retro -noreset &
$ DISPLAY=:29.0 strace -o "$(mktemp -- /tmp/strace.XXXXXXXX)" \
-- xterm -xrm "*VT100.faceName: Bitstream Vera Sans Mono" \
-xrm "*VT100.faceSize: 12" -hold -e ascii &
$ DISPLAY=:31.0 strace -o "$(mktemp -- /tmp/strace.XXXXXXXX)" \
-- xterm -xrm "*VT100.faceName: Bitstream Vera Sans Mono" \
-xrm "*VT100.faceSize: 12" -hold -e ascii &
$ DISPLAY=:29.0 strace -o "$(mktemp -- /tmp/strace.XXXXXXXX)" \
-- xterm -xrm "*VT100.font: -xos4-terminus-medium-r-normal\
--32-320-72-72-c-160-iso10646-1" -hold -e ascii &
$ DISPLAY=:29.0 xwininfo -root -tree

xwininfo: Window id: 0x42 (the root window) (has no name)

Root window id: 0x42 (the root window) (has no name)
Parent window id: 0x0 (none)
2 children:
0x40000c "ascii": ("xterm" "XTerm") 1284x772+0+0 +0+0
1 child:
0x400018 (has no name): () 1284x772+0+0 +1+1
0x20000c "ascii": ("xterm" "XTerm") 804x484+0+0 +0+0
1 child:
0x20001c (has no name): () 804x484+0+0 +1+1

$ DISPLAY=:31.0 xwininfo -root -tree

xwininfo: Window id: 0x42 (the root window) (has no name)

Root window id: 0x42 (the root window) (has no name)
Parent window id: 0x0 (none)
1 child:
0x20000c "ascii": ("xterm" "XTerm") 804x484+0+0 +0+0
1 child:
0x200018 (has no name): () 804x484+0+0 +1+1

$

The test is terminated by terminating the X servers involved.

A cursory look at the resulting trace files shows that xterm
uses writev to send requests to the X server, and recvfrom and
recvmsg to retrieve the responses from there. These syscalls
do not seem to be used for anything else, either.

Hence, we can gather the totals as follows.

$ perl -e '
use common::sense;

## Process the inputs
my (@argv, %sysc, %sum) = @ARGV;
while (<<>>) {
my ($sysc, $len)
= m { ^ (writev|recv(?:from|msg))\(3, .* = \s* ([0-9]+) \s*$ }x
or next;
$sysc{$sysc} = undef;
$sum{$ARGV} //= { };
$sum{$ARGV}->{$sysc}
+= $len;
}

## Report the accumulated totals
my @sysc
= sort { $a cmp $b; } keys (%sysc);
printf ("%8s", $_)
foreach (@sysc);
printf (" %11s\tfilename\n", "sum");
foreach my $k (@argv) {
my $sum = 0;
foreach (@sysc) {
printf (" %7d", $sum{$k}->{$_});
$sum += $sum{$k}->{$_};
}
printf (" %11d\t%s\n", $sum, $k);
}' -- /tmp/strace.58iaUK2Q /tmp/strace.6vNta0GE /tmp/strace.aVjKKjjW
recvfrom recvmsg writev sum filename
3137656 42916 150620 3331192 /tmp/strace.58iaUK2Q
4052104 120140 1014592 5186836 /tmp/strace.6vNta0GE
3137876 42728 25460 3206064 /tmp/strace.aVjKKjjW
$

So, first of all, there appears to be a *lot* of traffic
going from the X server back to client. Second, it certainly
looks like strace.58iaUK2Q and strace.aVjKKjjW have comparable
amounts of X traffic to them, while the considerably larger
strace.6vNta0GE is, at a guess, is the file corresponding to
the case of a Freetype font rendered on a non-Xrender server.

To check it out:

$ grep -m1 -- . /tmp/strace.58iaUK2Q /tmp/strace.6vNta0GE /tmp/strace.aVjKKjjW
/tmp/strace.58iaUK2Q:execve("/usr/bin/xterm", ["xterm",
"-xrm", "*VT100.faceName: Bitstream Vera "..., "-xrm", "*VT100.faceSize: 12",
"-hold", "-e", "ascii"], 0x7ffda5cb8d00 /* 33 vars */) = 0
/tmp/strace.6vNta0GE:execve("/usr/bin/xterm", ["xterm",
"-xrm", "*VT100.faceName: Bitstream Vera "..., "-xrm", "*VT100.faceSize: 12",
"-hold", "-e", "ascii"], 0x7ffe24f376f0 /* 33 vars */) = 0
/tmp/strace.aVjKKjjW:execve("/usr/bin/xterm", ["xterm",
"-xrm", "*VT100.font: -xos4-terminus-medi"...,
"-hold", "-e", "ascii"], 0x7fff4b111710 /* 33 vars */) = 0
$

Well, color me surprised! The traffic requirements of xterms
using bitmap and Freetype fonts are very close indeed, so long
as Xrender is available (and further presuming that the writev
difference is mostly one-time overhead), and yet regardless of
the font used, xterm is hardly 'lightweight' when it comes to
X traffic.

Further test runs with xtrace(1) have revealed that xterm(1)
does several QueryFont requests, each resulting in a 0.75 MiB
response from the X server. (Which is something at odds with
my prior experience of running X clients, including xterm, over
a 14400 bit/s modem connection.) My guess is that sticking to
an '8-bit' font might resolve that.

--
FSF associate member #7257 np. Frog Dreaming by Nodal

Ivan Shmakov <ivan@siamics.netNOSPAM.invalid> writes:

> I don't see why it might differ between VNC and X, but it's been
> some time since I've last been using X over SSH (to any extent),
> so I might be forgetting some important details.

I don't think badly-written VNC implementations tend towards the habit
of calling _XReply upon each input event, as so many X clients written
today seem to. Emacs is thankfully free of that misbehavior ;-)