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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 ;-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)