Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!bloom-beacon!ZIA.AOC.NRAO.EDU!cflatter
From: cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters)
Newsgroups: comp.windows.x
Subject: Re: A tirade about inefficient software & systems
Message-ID: <9011010052.AA05115@zia.aoc.nrao.edu>
Date: 1 Nov 90 00:52:02 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 71


> 1) The X Window System and GUIs built on X are expensive in terms of CPU,
> memory and network resources. Discuss. You should compare the X philosophy
> with competing network windowing philosophies such as those based on
> PostScript.

Taking NeWS as an example of a PostScript based window system:

X11 is not significantly more expensive than NeWS as far a CPU is related.
However the load may be distributed rather differently:  some computations
that are done on the client side (eg. user coordinate/screen coordinate
transformations) may be done on the server side.  Note that this implies
that a NeWS terminal, should such a beast exist, would have to be more
powerful than an equivalent X terminal.

NeWS has a reputation as a memory hog.  The X11/NeWS server that comes
with OpenWindows 2.0 is much less piggy than the previous version when
running NeWS clients but NeWS clients probably do not require markedly less memory (on either side of the client-server link) than X11 clients and
may require more (I'm not sure how to measure this).

The only area mentioned above where NeWS wins over X is in the
interprocess communications overhead:  since clients download PostScript
code to the server no client-server transfers are necessary to repair
windows after expose events.

I also believe that NeWS is rather better at handling exceptions (eg. servers
running out of memory) than X, but there is no fundamental reason why X
should not improve in this regard in future releases.

Working against NeWS (and presumably Display PostScript) is the fact that
they impose the PostScript imaging model on their clients, which may not
be appropriate for some applications.  X11 uses a very low-level raster
graphics model which may act as the foundation for any of a number of
higher level models (including PostScript --- see GhostScript as an example).
Furthermore, I suspect that many programmers are not comfortable with the
though of writing PostScript code;  certainly the idea of maintaining a
few hundred lines of someone elses PostScript code would give *me* night-
mares.

> I'm no Xpert, but has the industry got it wrong?

I don't think so.  If it did it only got things slightly wrong.

From what I've seen so far it is quite possible to merge X and PostScript
based systems to get the best of both worlds.

> The fact that I hear people from Sun tell me ``Our implementation of
> Open Look is great --- but you need 16 Meg in your SPARCstation'' alarms
> me. 

This just ain't so.  I'm running OpenWindows 2.0 on a SPARCstation 1 with
only 8 Mbytes of memory and, as long as I don't start doing silly things
like grabbing hold of huge globs of shared memory, it hums along very
nicely thank you (not that that stopped me from asking for more memory).
Now OpenWindows 1.0.1 really dragged.  That turns out to have been due 
to the window manager being written in PostScript and, consequently, being
a real memory pig (I rest my case).

			Chris Flatters

Postscript (not the trademarked kind):

> The fact that X applications potentially generate significant numbers
> of packets and eat up CPU cycles even when there's no user interaction
> alarms me (ever watched a LANalyser when xeyes is running?).

Xeyes is continually polling the server to find out where the pointer is.
This sort of thing is not normally necessary in an X application.  The only
serious application I can think of that does anything like this is xclipboard
which appears to continuously poll the server to get the current value of
the CLIPBOARD selection.