X11 bashing

Byron Rakitzis byron at archone.tamu.edu
Wed Apr 17 14:36:37 AEST 1991


In article <1991Apr17.040918.12203 at Think.COM> barmar at think.com (Barry Margolin) writes:
>In article <1991Apr16.210107.41817 at eagle.wesleyan.edu> amolitor at 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 at archone.tamu.edu



More information about the Comp.unix.internals mailing list