🚀 go-pugleaf

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