Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!bu.edu!bucasb!slehar From: slehar@bucasd.bu.edu (Steve Lehar) Newsgroups: comp.sys.sgi Subject: Re: SGI's migration to X Message-ID: Date: 30 Aug 90 21:32:22 GMT References: <208@voodoo.UUCP> Sender: news@bu.edu.bu.edu Organization: Boston University Center for Adaptive Systems Lines: 63 In-reply-to: zombie@voodoo.UUCP's message of 28 Aug 90 17:30:22 GMT 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@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)