SGI's migration to X

[Steve Lehar]

Having worked with   both SGI and   X,  I've gotta  say  that  the SGI
windowing and  graphics   system is the  most  beautiful, simple, well
written, easy-to-use and elegant windowing system  I have ever had the
pleasure to work with! You look it  up in  the manual, type it in, and
HEY PRESTO! it works just as advertised!

Now X is a whole nuther matter!  The system is impossibly complicated,
the documentation  is obscure, and nothing  ever works without sending
email to the x consortium gurus themselves!

Just as an example- I wanted to write  values  0 to 255  into an 8 bit
color map for image processing.  Sounds simple?  Well, just to get the
window to appear on the screen takes a couple of pages  of hyroglyphic
code, but it always comes up coal black, I cannot seem to get anything
in to the color map except 0,0,0,0,0,0...   Finally, in exasperation I
email to   the  gurus.  "Oh    yeah,  we forgot   to  mention   in the
documentation, you have to left-shift the values by 8 bits because the
color map only uses bits 9-16 in an 8-bit  color map!"   So  to load a
value 10, you load  10<<8!  Why? Oh  you see,  some machines have more
than 8 bit color maps, so it's for compatability- although that hasn't
been implemented yet, so there IS no compatibility, only confusion.

Another example- they  provide an  image structure  for use with image
processing, which works  fine, and they  supply  routines  for quickly
displaying such  images and performing  graphics in them like  drawing
colored boxes  and circles.  The  trouble  is  that if  you want to do
image processing you have to get your image  data into that structure,
and the only  routine they provide sends the  pixels  over one by one,
OVER THE NETWORK! so that even when you display  from your own private
terminal to your own  private screen it  goes...  "Prepare  to receive
pixel", "sending pixel", "confirm receipt of pixel", "prepare for next
pixel"... and so forth and of course  it takes an  eternity to  send a
whole image!  I sent off to the gurus again and got a reply that  I am
still trying to implement after two months.  In  the meantime I put up
with a system where it is quicker  to process my  image  than it is to
display the result on the screen!

And then there are other little annoying things- like you  cannot tell
X in advance where  you want your  window to arrive,  the only way  to
position it is by hand with the mouse.  So I type in "display image A,
B and C" and off it goes sending pixels one by one while  I go to work
on something else, but just as SOON as it's  ready it interrupts me in
the middle of my keystroke- suddenly the terminal will not  respond to
anything at all except the positioning of image A.  Then as I get back
to my typing I am interrupted again by image B and then image C.  (and
they don't necessarily come up in that order)

Now I know that X is designed to run on any hardware, which is  why it
is so complicated, while the SGI stuff only runs on  SGI, and  that is
why  it is so simple  and elegant.   Nevertheless,  I think SGI did an
EXCEPTIONAL job in their graphics software, and  I  would not hurry on
over to X  unless I  were  absolutely FORCED  to  do  so!  X is messy,
inordinately complicated, atrociously documented and unreliable. (My X
image windows  are prone to   suddenly  disappearing if  they've  been
around for a while) My advice is to stick with SGI!

--
(O)((O))(((O)))((((O))))(((((O)))))(((((O)))))((((O))))(((O)))((O))(O)
(O)((O))(((              slehar at bucasb.bu.edu              )))((O))(O)
(O)((O))(((    Steve Lehar Boston University Boston MA     )))((O))(O)
(O)((O))(((    (617) 424-7035 (H)   (617) 353-6425 (W)     )))((O))(O)
(O)((O))(((O)))((((O))))(((((O)))))(((((O)))))((((O))))(((O)))((O))(O)