Article 152834 of comp.os.vms:
Alan Frisbie wrote:
> 
> In article <4ubhlc$hu7@sjx-ixn6.ix.netcom.com>,
> John Henning <i4get@ix.netcom.com> writes:
> 
> > You are correct that performance of the graphics console on some
> > AlphaServer 1000's is slow.  For whatever it's worth, this is due
> > to the graphics subsystem, not the CPU.  I guess the
> > theory here is that on a server you only need a bare minimum of
> > graphics support - enough to do system administration tasks.
> 
> I can understand that a system administrator doesn't need
> blinding-fast 3D animation.   However, system administration
> usually involves tasks like editing startup files, etc.
> When window scrolling is faster on a VAXstation-II (admittedly
> running VWS) than on a brand-new AlphaStation 1000A, the new
> owner is likely to be less than thrilled.
> 
> Perhaps the people who configure these systems should be
> forced to actually use them.   Or is that too radical a concept.   :-)
> 
> > Have you tried displaying an X-window remotely?
> 

  The original intent of the hardware designer was that they expected a significant
  amount of the sales as network servers, not running OpenVMS or UNIX.  They *had*
  to have graphics for it to boot, and they wanted the absolute cheapest solution...
  This happens to be a bottom-of-the-line Cirrus SVGA chip, no blit engine, just a
  hardware cursor.  And it's on the ISA bus.  The server is a cross between a generic
  VGA server, and a dumb frame buffer.  Doing byte I/O on the ISA bus is S*L*O*W.  And
  the worst is scrolling, since it's a screen-to-screen copy, which means the data is
  read in over the ISA bus, and written out over the ISA bus.

  To put the final nail in the coffin, only 1/2 MB of memory was provided, limiting
  the screen resolution to 800x600 @8bit pixels (with some work, we could have done
  a 1024x768 @4bits.... yuck).  Needless to say, VMS and UNIX believed always believed
  that this was not adequate for "general" use as a X11 workstation head.  I've always
  insisted that we make sure to let users know that the built-in graphics are
  intended primarily for booting, software installation, and system management
  functions... but not as a general-purpose graphics terminal. 

  My recommendation is to buy a ATI Mach64 ISA card (I forget the tradename that ATI
  uses for it, but DEC sells it too).  This will give you "reasonable" performance for
  a relatively low price tag.  If you don't mind using a PCI slot, the ATI Mach64 "CX"
  card is a cheap alternative, or the S3 Trio64 -- both will give very good performance
  at a low price.  The S3 Trio64 is also available from DEC, or from Dimond, or #9.

  I was annoyed enough about the graphics to do some rewriting of the server code to
  make it faster.  The best I could do was to create a "virtual" frame buffer server
  that does selective blits to the screen from an offscreen virtual cfb.  While not
  "great" it makes it tolerable for non-graphics-intensive stuff like dxterms.  The
  new stuff will show up in late vintage V6.2-based hardware releases, and in the next
  VMS functional release (with X11R6)... I'm not sure when/if it will merge with the
  UNIX code.

  The follow-on hardware uses a Cirrus chip with a blit engine, and a socket to allow
  a full 1mb of DRAM.