Thanks very much, a very valuable introduction. Have been writing a small
windowing gui system for embedded projects and part of the effort has been
to get a historical perspective on early ws windowing systems, which were
similarly constrained by low throughput cpu's and small memory sizes. The
two dec wrl reports on dumb colour frame buffer programming have also been
very valuable. Have a bit of info as on Sun's NeWs system, but am still
digging for info on others. It was really quite difficult to get decent
graphics response and the use of (for example) scaled integer arithmetic,
rather than floats, must have contributed quite a bit, especially if the
data could be organised to enable the use of shifts, rather than multiply
and divide instructions.
The VWS footprint was fairly small. The most complex part of VWS was due to
the decision to provide guaranteed backing store. Each application created
a viewport and then could map one or more windows into the viewport. From
the applications point of view - nothing else was running on the graphics
screen.
Overlapping windows and backing store were in the early days the toughest
thing to get right. Remember that the original MS Windows design supported
tiled windows only.
The real speed limiter between VWS and X11 was that the UIS interface was
procedural and did direct rendering (in the case of the MFB) and a "near"
direct rendering on the GLX engine (packets queued to a device driver
drawing queue). X11 generates protocol packets that are processed by
another process (adding a context switch, scheduler delays, and protocol
parsing). Microsoft found out the hard way just how much of a performance
hit this was when NT implemented it's GDI originally in the same manner.
Even with assists like the LPC interface it was much slower.
Also VWS was tightly coupled to VMS. Taking advantage of AST's for example.
You could make UIS calls from any mode. The terminal emulator ran as an AST
driven extension to a terminal port driver. Etc.
Post by FredKVWS was only implemented on two graphics engines before it was retired -
a monochrome frame buffer, and the GPX graphics engine.
I think vws was available on the uVax II/GPX and the monochrome frame
buffer variant. around the vms 4.7 to 5.4 timeframe and was faster than
Decwindows on X, which really needed more memory and cpu throughput.
Decwindows ran far better on the later KA650 series.
It was known at the time that DW was being written that it would be slower
than VWS on existing HW. But that as HW got faster, it would not matter.
Post by FredKUISX was implemented as a way to migrate VWS applications. UISX
implemented the entire VWS programming model on top of X11. In fact, the
application did not even need to be re-compiled.
That sounds like typical dec foresight :-)...
It only sounds like foresight. In reality, the DW program manager believed
that VWS use would ramp to zero in a linear ramp over a calendar year once
DW became available. This proved not to be true, and I proposed UISX as one
of a group of porting/migration tools.
I was amazed UISX worked as well as it did, but I'm not sure how much use it
ever saw. I ported it to Alpha (and even fixed the VAX version so that it
did not link against the system image to allow it to be VESTed) - but I'm
not sure Touch ever shipped the Alpha version.
Trivia note. UISX was originally named XUIS - but it had to be changed
because the X11 people wanted the name "XUI" and the copyright/trademark
people don't like things that end with "S" because you can't always tell if
the "S" is part of the name - or a plural, or posessive, etc.