Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!haven!ncifcrf!lhc!adm!news
From: preece@urbana.mcd.mot.com (Scott E. Preece)
Newsgroups: comp.unix.wizards
Subject: Re: X11 bashing
Message-ID: <26550@adm.brl.mil>
Date: 12 Apr 91 16:28:06 GMT
Sender: news@adm.brl.mil
Lines: 53

We have seen a long string of notes beating on X as a resource hog, a
waste of the hardware performance improvements of the last few years, a
threat to reliability, a performance disaster, and various other kinds
of mistake.  Many of these things are true, but they are both misleading
and unproductive.

The performance and resource costs of X are being addressed in several
ways, by the X Consortium, by the various vendors of add-on toolkits,
and by platform vendors selling X-based products;  major algorithm
changes, reconsideration of resource allocation policies, and the
growing availability of shared libraries should make the next release a
significant improvement over X11R4.  X is relatively
immature technology and its authors are only beginning to switch from
constructing new functionality to examining the details of the
implementation and its operating characteristics.  This is hardly a
startling life-cycle.  You *can't* realistically evaluate the
performance characteristics of a product like X until its functionality is
complete enough that to allow review of real applications in real use.

Most of the critics have failed to suggest what they would have liked to
see as a windowing interface instead of X.  Most of the other windowing
systems are built on kernel implementations; most UNIX architects have
reached the point where they become nauseated at the idea of adding
additional kernel functionality of any kind.  The open availability of X
and the fact that it is a user-level implementation are extremely
powerful arguments in the current technological and marketing environment.
If, as some argue, X is a fundamentally broken model and the division of
labor between client and server inherently implies worse performance
than some other model, they are free to produce a convincing
demonstration of the superiority of some other scheme; from what I've
heard, the other schemes that have been suggested have other problems
that are just as severe.

Many of the notes have pointed at 3D appearance as something that
carries no advantage and costs a lot.  While I tend to agree that it
adds little to the utility of the GUI (and I, in fact, run in an Athena
look and feel rather than a Motif look and feel), I would be interested
in any hard statistics people could present on the *cost* of the fancier
look.  I would seriously surprised if it were anything like the numbers
that people have used here (without any supporting citations).  Frankly,
for real end users, I would expect that once a user starts up an
application they tend to stay in it for long periods and do relatively
few operations that would involve any effort in support of the 3D effects.
I don't have any numbers, either, but I think my supposition better fits
the expected model of end-user use of applications.

scott

--
scott preece
motorola/mcg urbana design center	1101 e. university, urbana, il   61801
uucp:	uunet!uiucuxc!udc!preece,	 arpa:	preece@urbana.mcd.mot.com
phone:	217-384-8589			  fax:	217-384-8550