Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!tektronix!sequent!mntgfx!dclemans
From: dclemans@mntgfx.mentor.com (Dave Clemans)
Newsgroups: comp.sys.amiga
Subject: Re: The Next Generation
Message-ID: <1987Nov17.084427.8635@mntgfx.mentor.com>
Date: Tue, 17-Nov-87 11:44:24 EST
Article-I.D.: mntgfx.1987Nov17.084427.8635
Posted: Tue Nov 17 11:44:24 1987
Date-Received: Fri, 20-Nov-87 03:33:16 EST
References: <2785@megaron.arizona.edu>
Organization: Mentor Graphics Corporation, Beaverton Oregon
Lines: 20

Having virtual memory DOES NOT mean that there will be large overheads
in opening windows, dragging windows, etc. (the example given in the
referenced message was tens of seconds to open a window on a Sun 2/50,
system unable to keep up with cursor movement when dragging windows,
etc).

As an example you might want to look at a current Apollo system,
which does use virtual memory, processes in different address spaces,
etc.  It does not exhibit any of the timing problems described
in the previous message (window opens are essentially instantaneous,
...).  

Part of this comes from having windowing, mousing, etc. tightly
integrated into the system.  Another part has to do with the
order that operations are done in; from the description in the
previous message it sounds like on that persons Sun that the window
is created last, after the new process is forked.  On the Apollo
the window is created first.

dgc