tada@athena.mit.edu (Ivan Tadayoff) (01/29/88)
In article <598@nitrex.UUCP> rbl@nitrex.UUCP ( Dr. Robin Lake ) writes: >In article <635@ndmath.UUCP> milo@ndmath.UUCP (Greg Corson) writes: >>If you get a MicroVax 2000 with Ultrix you get X windows right? Ok, so >>what do you get when you buy a Vaxstation 2000 with VMS? What kind of >>graphics/windowing software is included and how would you compare it >>with X windows under Ultrix? >> >We have a VAXstation 2000 with color. With VMS you get "UIS" and "GKS" >(maybe we paid for GKS?). ... >The biggest problems I've found is that the CPU doesn't have enough horsepower >to concurrently handle the windowing, menus, and graphics when trying to do >interactive graphics. Things start to break up, menus slow down, etc. Also, >moving a window is SOOOO much harder than it is on the Macintosh that sits >alongside the VAXstation! AND, if I resize the GKS window, it does not get >repainted! Right size, but nothing there. For the record, yes, you (or someone) did pay for GKS. We have it here and I looked into at one point for graphics programming, but it doesn't have the full functionality of UIS, and furthermore it calls UIS to actually execute the graphics instructions, so it's slower. The CPU can handle the windowing, etc, but you probably don't have enough memory. DEC only sells 2000's with up to 6M of memory, but there are at least 2 third party companies that sell 16M boards for it. Probably a very good investment for the performance difference it will make, especially if you have less than 6M now. I don't know how GKS handles things, but under UIS a window is repainted when moved/resized. Also, under UIS you can set up an asynch routine to be called if the window is moved or resized. You can proably do that from GKS also and have your program redraw the window. As far as comparing UIS and X: There are a couple of main differences. First of all, X is implemented on many computers, so X code is more portable. (Yeah, I know, I haven't told anybody anything new yet.) Under X, when a window is moved or uncovered, the program has to check for that and repaint the window, requiring the programming to keep track of what the screen looks like at all times. UIS automatically redraws a window, but it need to store the window somewhere, so it takes more system memory. (That's mostly intuitive. I know UIS requires a fair amount of main memory, and I know people have had gillions of windows open under X on machines with only 1M.) In X, when an "X-event" (mouse click, key typed while in window, etc.) occurs, it's put into a queue which the program can read. (Actually, only the x-events which the program requests are put in the queue -- others are ignored.) This means that the program has to keep checking the queue periodically. In UIS, window events trigger asynchronous system traps (AST's) which cause the execution of program segments. Unfortunately, AST's will not interrupt each other (see comp.os.vms article 4214 for an explaination), so if you want to have the user click on a menu option and enter a line of text, you have to return from the AST the handled the mouse click and branch to another routine because the keyboard AST can't execute until the mouse AST has completed. In that case, you're reduced to checking a status every so often anyway in order to handle the input (which is just like checking a queue). One final comparison -- X11 treats everything as one byte/pixel whether you're on a monochrome or color system, so it is considerably slower than UIS which is specific for monochrome or color. (The code is the same, but the hardware knows what size to make things.) They both have advantages and disadvantages, and which one is "best" depends a lot on the specific application. Sorry if this is too long-winded. I hope it helps someone out there....
rws@zermatt.lcs.mit.edu (Robert W. Scheifler) (01/30/88)
>> AND, if I resize the GKS window, it does not get >> repainted! Right size, but nothing there. One of the problems with GKS, and other graphics standards that predate window systems, is that they tend to believe that they own the screen, and that the screen doesn't change size, and that the screen doesn't spontaneously combust. I do not believe vanilla GKS has any information path back to the application to tell it that the image needs to be redrawn. You could argue that the GKS internals should automatically redraw the image from the segments, and I believe there are GKS implementations that do this, although you then get into questions about how a change in size should affect the view transforms. > Under X, when a window is moved or uncovered, the program has to check > for that and repaint the window, requiring the programming to keep > track of what the screen looks like at all times. UIS automatically > redraws a window, but it need to store the window somewhere, so it > takes more system memory. X11 has a mechanism (protocol) for the application to request this same service, although existing X11 development servers to my knowledge do not yet implement this. I do not know whether various product servers will. > One final comparison -- X11 treats everything as one byte/pixel > whether you're on a monochrome or color system, so it is considerably > slower than UIS which is specific for monochrome or color. (The code > is the same, but the hardware knows what size to make things.) This is completely silly. The X11 protocol certainly is not brain-damaged in this way. And if you've run certain development servers on certain non-Digital hardware, and noticed that it runs substantially faster on 1-bit screens than 8-bit screens, you would realize that the code obviously can be different. Bob Scheifler MIT X Consortium
tada@athena.mit.edu (Ivan Tadayoff) (01/30/88)
In article <3476@mit-vax.LCS.MIT.EDU> rws@zermatt.lcs.mit.edu (Robert W. Scheifler) writes: > [my silly statements:] > > One final comparison -- X11 treats everything as one byte/pixel > > whether you're on a monochrome or color system, so it is considerably > > slower than UIS which is specific for monochrome or color. (The code > > is the same, but the hardware knows what size to make things.) > >This is completely silly. The X11 protocol certainly is not >brain-damaged in this way. And if you've run certain development >servers on certain non-Digital hardware, and noticed that it runs >substantially faster on 1-bit screens than 8-bit screens, you would >realize that the code obviously can be different. > > Bob Scheifler > MIT X Consortium My apologies for any errors. A good friend of mine has been doing a fair amount of X programming at MIT and uses only X10 because he said X11 was too slow becuase of the byte/pixel reason. Perhaps he's wrong, perhaps the implementation he's using is brain-damaged even though the protocol itself isn't. Thanks for setting the record straight. (I guess that teaches me to try and write intelligent comments late at night. :-)