Xref: utzoo comp.sys.dec:486 comp.os.vms:4345 Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!bloom-beacon!athena.mit.edu!tada From: tada@athena.mit.edu (Ivan Tadayoff) Newsgroups: comp.sys.dec,comp.os.vms Subject: X vs. UIS on uVax 2000 (Was Re: MicroVax 2000) Summary: long-winded ramblings Message-ID: <2629@bloom-beacon.MIT.EDU> Date: 29 Jan 88 02:50:17 GMT References: <635@ndmath.UUCP> <598@nitrex.UUCP> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: tada@athena.mit.edu (Ivan Tadayoff) Organization: Massachusetts Institute of Technology Lines: 71 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....