Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!archone!byron
From: byron@archone.tamu.edu (Byron Rakitzis)
Newsgroups: comp.unix.internals
Subject: Re: X11 bashing
Message-ID: <14820@helios.TAMU.EDU>
Date: 17 Apr 91 04:36:37 GMT
References: <26550@adm.brl.mil> <1991Apr16.210107.41817@eagle.wesleyan.edu> <1991Apr17.040918.12203@Think.COM>
Sender: usenet@helios.TAMU.EDU
Organization: College of Architecture, Texas A&M University.
Lines: 46

In article <1991Apr17.040918.12203@Think.COM> barmar@think.com (Barry Margolin) writes:
>In article <1991Apr16.210107.41817@eagle.wesleyan.edu> amolitor@eagle.wesleyan.edu writes:
>>Software development cycles should not proceed as: add every concievable
>>feature, then tune. Something more like: get something minimally useful,
>>tune, then see if something more is needed. If not, STOP. If more
>>features are needed, add them, and re-tune.
>
>I never used anything earlier than X10 myself, but I assume the first few
>versions of X were minimally useful, and eventually they decided all the
>features of X11 were needed.  The X developers were not just adding
>features for their own sake; they were trying to solve real problems.
>

In all fairness to the designers of the X protocol, it was one of their
stated principles "which guided us through the early X design: Do not
add new functionality unless an implementor cannot complete a real
application without it."

[From Sheifler, Gettys, Newman, "X Window System C Library and Protocol
Reference, p.xxi]

Still, it's a pity that the X protocol itself is so terrible.

>>	I rather suspect that this windowing system could be written to be
>>terrifyingly fast, and to consume negligable resources. I further suspect
>>that it would provide a high percentage of the *useful* functionality of X.
>
>I don't think our image processing and animation people would consider
>a bunch of 24x80 terminal emulators to be a "high percentage of the useful
>functionality of X."

I don't think "image processing and animation" people would consider X
to be a satisfactory solution to their graphics problems either!

Let's face it: X was not designed with high performance graphics in mind.
Look at the colormap fiasco, and the fact that every call to the X server is
effectively a context switch. You just can't make good graphics code work
under such poor conditions.

I think the successor to X will somehow allow dynamic reconfiguration
of the server (via, say, an interpreted language) so that the network/context
switch bottleneck can be reduced.

--
To reveal art and conceal the artist	| Byron Rakitzis, Texas A&M.
is art's aim.  -- Oscar Wilde.		| byron@archone.tamu.edu