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