Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!ubc-cs!lowe
From: lowe@cs.ubc.ca (David Lowe)
Newsgroups: comp.windows.x
Subject: Re:  X terminals/ pc X terminals
Message-ID: <10257@ubc-cs.UUCP>
Date: 29 Oct 90 00:36:11 GMT
References: <9010240817.AA15043@Larry.McRCIM.McGill.EDU> <2259@lupine.NCD.COM> <69417@lll-winken.LLNL.GOV>
Sender: news@cs.ubc.ca
Organization: University of British Columbia, Vancouver, B.C., Canada
Lines: 67

In article <69417@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey Leedom) writes:
>  We just ran a head to head comparison of the NCD/XRemote against the
>GraphOn.  The GraphOn outperformed the NCD on almost all operations by
>very wide margins ranging from %200 to %1000.  The NCD/XRemote did
>outperform the GraphOn on some stippled operations which seem to indicate
>a failing in the GraphOn graphics protocol.  I'm waiting for copies of
>the new software to reperform our tests.
>  The GraphOn is currently the obvious choice for serial line X11
>operation.  [rest deleted]

   Let me put in a good word for the NCD XRemote.  I have been using an
NCD 19 with the XRemote PROMs over a 9600 baud modem for the past 2
months.  I have found it to be a very good solution for working at home.

   The best aspect of the NCDs is their excellent displays, with 1280x1024
resolution, 19 inch size, 70 hz non-interlaced, and paper-white phosphors.
The display is better in every respect from the SparcStation in my office,
and it is completely silent.  The last time that I checked out the
GraphOn, they only had a tiny fraction of the resolution and it was
definitely a lower-end product.  There is nothing wrong with that, as
their price was also far less than NCD's.  However, for those who can
afford an NCD 19 (very roughly U.S.  $3500 with XRemote plus $1000 for a
good modem) it provides a superb display.

   As for speed, the problems occur mostly on application startup.  For
programming and most other tasks, the limiting factor is simply shipping
ASCII characters over the phone line, and I doubt that there are
significant differences in the compression technologies.  Presumably Emacs
runs at the same speed on any of these systems as it has little
interaction with the X protocol.  The worst speed problem on the NCD is in
loading fonts.  It often takes up to a minute to download a font, and then
the font is lost as soon as the client requesting it is closed.  NCD
claimed that they would have general font caching implemented by now, but
I haven't heard from them.  The workaround is to set up your clients to
use only a few standard default fonts.  Also, there is a bug in the server
software for displaying large bitmaps that causes the client to die, which
they have known about for months and haven't fixed.  But these problems
have all proved relatively minor compared to the value of having a large,
high-quality display (and good Unix-style keyboard).


>    2.	It would be trivial to implement the client side software on PCs
>	and GraphOn still hasn't done this.  I'm waiting on buying a
>	Macintosh on this issue.
>

   This is something that represents a tremendous market opportunity
for GraphOn or anyone else.  GraphOn could probably make much more on
each copy of this software than its margin on each X terminal, as well
as sell to a much larger market.  The PC would be an ideal platform
for a home X terminal, as it could be used for many other tasks as well.
Also, its hard disk could be used to cache fonts and other downloaded
information to make it much faster than limited-memory PROM solutions.

   An intersting question is to think about why the GraphOn protocol is
apparently faster than the basic X protocol.  The whole idea of the X
protocol was supposed to be efficient communication to a display server!
If it is better over serial lines, then it should also be good for
reducing general network loads and interprocess communication.  Best of
all, it only needs a fixed amount of memory in the display.  This gets
around one of the fundamental problems with X, which is that it can fail
at random (from the client's point of view) due to a lack of memory.
Maybe all X terminals should adopt this solution.

-- David Lowe
   Computer Science Dept.
   Univ. of British Columbia