Re: GEM/X

[hyc@hanauma.jpl.nasa.gov]

  What you wrote:
  > What about NeXT ?  X uses by far the most CPU resources, and GEM the least,
  > so what about something in between .. like the NeXT GUI?  It could be
  > simulated either by adding to GEM, or rewrite GEM to call NeXT-like objects
 .
  
  NeXTstep would he even worse than a simple X server on an ST or Falcon;
  Display PostScript is computationally expensive, and we don't have enough
  computrons to spread around.  Have you seen how slow Ghostscript and
  Ultrascript (two PostScript emulators) are on a 68k?  *shudder*

Agreed, anything PostScript based would be a worse drain than even X...
  
  I wonder if a virtual desktop for MGR would be possible, and how "slow"
  it would be?  MGR is a pretty minimal (ie, fast and not too memory hogging)
  graphical environment...  Maybe someone who's actually been using it
  (is Howard Chu on this list?) has been doing some work at making it more
  attractive to users?

I've had to give up using MGR to write stuff in MultiTOS on the Falcon. As
such, I guess now I'm more interested in ideas to optimize GEM than to use
alternate window systems.
  
  It's a pity Atari decided to put such a brain-dead MMU into the original
  ST.  4M isn't enough for all of this and a C compiler, let alone a C++
  compiler.  :-(

Well, maybe not for a GNU compiler, anyway... Lots of people got lots of
useful work done on Sun 3/50s, 4 MB, 12.5 MHz 68020... But even so, a real MMU
would be nice. A CPU that supported virtual machine operations would be nice.
Like a 68030...

Of course, you can still get 12 MHz 68010s from Motorola, and they ought to be
able to operate at 16 MHz. Stick one of those in a 16 MHz accelerator board,
and you may be able to get by a while longer...