🚀 go-pugleaf

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....