Path: utzoo!attcan!uunet!husc6!uwvax!rutgers!bellcore!texbell!sugar!ficc!peter
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.sys.next
Subject: Re: Next and the competition
Message-ID: <2572@ficc.uu.net>
Date: 27 Dec 88 14:52:07 GMT
References: <29866@tut.cis.ohio-state.edu> <5567@cbmvax.UUCP> <361@internal.Apple.COM>
Organization: Xenix Support
Lines: 72

In article <361@internal.Apple.COM>, casseres@Apple.COM (David Casseres) writes:
> In article <5567@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes:
> 
> >Aargh!! No, no!  Please don't say that this system doesn't support "SMART" 
> >refresh windows! Let the OS handle all aspects of a window.

I'm afraid, Dave, that simple-refresh has become somewhat of a standard.

With all the performance loss this implies.

> Gee, just what are "all" aspects of a window?

Everything in the window that needs to be managed as a result of other
programs' actions. This includes having the window obscured by other windows,
depth-arranged, and moved.

[ including acknowledgement of the users actions ]

To improve effective response time, yes. Certainly the menu system should work
asynchronously with the program, and so should statically located gadgets. In
the controls industry local acknowledgement has proven very effective in
cutting down user's frustration.

> Or maybe you mean that refreshing should only
> be done by saving the bits of the window's current image, then restoring
> them when a refresh is needed.

That's right.

> Too bad if the content of the window wanted
> to change before the refresh.

Nope, because since the task is rendering through a a library that handles
all the clipping rectangles anyway, it's trivial to have those rectangles
that represent the off-screen part of the window point to temporary bitmaps
of the right size and shape that are simply copied back in when the window
gets screen real-estate again.

We're talking about a multitasking operating system that routinely has many
windows run by many programs visible at once. Now, suppose you use simple-
refresh windows and then do something that requires several programs be
notified. Say, you move a middling size window from a place where it's
overlapping three other windows to off-screen.

With smart-refresh windows, the window mgr runs through the clip-list once, and
everything's fine.

With simple-refresh windows, the window mgr sends a message to each of the
programs, Now, it's got two choices... it can wait for the program to respond,
or it can let them update asynchronously.

In the first choice, the screen is effectively locked until (in this case) four
seperate programs get the message, do their rendering, and reply. this means
that any program has to be written so it will never wait more than a second
or so before checking the window mgr. This isn't so bad in Mach, with threads,
but it's a real pain on the Mac (Mac applications end up looking much like
device drivers).

In the second choice, the burden of waiting for programs falls on the user.
You have to realise that what you see on the screen isn't necessarily real
life.

In either case the perceived performance of the machine goes way down. My
Amiga (with a 68000) seems faster than a Mac-II (with a 68020) simply
because it has better real-time response to a user's actions. I find on the
Mac that I get in the habit of never arranging windows and sticking to one
program (instead of hopping around) because it's so frustrating.
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180.   `-_-'
Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net.                 'U`
Opinions may not represent the policies of FICC or the Xenix Support group.