21 Jun
2013
21 Jun
'13
7:21 a.m.
On 21 June 2013 15:43, David Riley <fraveydank at gmail.com> wrote:
On Jun 21, 2013, at 7:13 AM, Joachim Thiemann
<joachim.thiemann at gmail.com>
wrote:
Maybe - I'm actually curious if this really is the case. In the dark days,
I have done remote X over a 9600 baud modem with full Blinkenlights; there
is a significant amount of negotiation every time a window is created or
even a transient object like a pull-down menu (or the pop-up menu of
xterm). Implementations are typically synchronous as well - request
properties, wait for reply, request window to be drawn, wait for success,
etc...) so in addition to bandwidth, latency can be an issue.
Where does rendering of the text in an xterm happen? I remember xfs being
involved in some way, but it's all a bit hazy; but text-heavy programs
should work equivalently IFF rendering happens on the "client" (in X
terminology). In either case, (X or remote FB) the client sends the bitmap
deltas to the server (display).
The only circumstance where I could see the X concept be "better" (in the
responsiveness criterium) is large scrolled widows, under the assumption
that the entire underlying area is stored (pre-rendered) on the display
server, with the appropriate portion to be exposed under the control of the
server. However, I have no idea if that is actually the case with the
common X11 implementations, or if they just send "expose" events back to
the client which renders on demand.
Or, of course, one can make the argument that if your interfaces are
text-heavy, remote X11 is the wrong tool for the job and the task would be
better served with local xterm-equivalents with ssh connections and GNU
screen or tmux to provide persistence in case of network problems.
Cheers,
Joachim.
--
Joachim Thiemann :: http://jthiem.bitbucket.org ::
http://signalsprocessed.blogspot.com
Far better - and the common solution nowadays -
is to have a virtual
persistent framebuffer if you need network transparency. This is what
RDP
and VNC do, and from my perspective, do it pretty
well; any issues you
may
observe in current systems tend to be due to the
implementation.
Yes and no; for graphic-heavy things, a remote framebuffer is ideal, since
you'll essentially be duplicating that over X. But for other things,
especially text-heavy UIs, I'll go with X, especially over a slower
connection. The protocol is a lot more lightweight in the general sense.
I've seen some OK optimizations; Windows Remote Desktop is actually a lot
more speedy than I'd expect, even over a distance of several states.