Path: utzoo!attcan!uunet!husc6!bloom-beacon!bu-cs!purdue!decwrl!labrea!polya!ali
From: ali@polya.Stanford.EDU (Ali T. Ozer)
Newsgroups: comp.sys.next
Subject: Window Refreshing (Was Re: Next and the competition)
Message-ID: <5781@polya.Stanford.EDU>
Date: 23 Dec 88 15:27:40 GMT
References: <29866@tut.cis.ohio-state.edu> <5567@cbmvax.UUCP>
Reply-To: aozer@NeXT.com (Ali T. Ozer)
Organization: .
Lines: 29

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!  This is supposed to be a "real" computer with lots of
>memory.  If the application doesn't know how to refresh a window, it
>shouldn't have to.  Let the OS handle all aspects of a window.  Just cause
>the Mac doesn't (or didn't, maybe it does now?) handle such things doesn't
>mean the rest of the world should stay so barbaric.  
>Dave Haynie  "The 32 Bit Guy"     Commodore-Amiga  "The Crew That Never Rests"

Don't panic! NextStep does support smart-refresh windows, and almost all 
applications use them. There are actually three types of refreshing:
  
   NONRETAINED, where windows are told to redraw parts of themselves 
	     whenever necessary.
   RETAINED, where covered parts of the window are stored in a backup area.
   BUFFERED, like retained, except all drawing goes to the backup area and
	     has to be explicitly flushed by the programmer. This allows
	     a simple way to double-buffer.

Turns out that instead of just saving the covered parts of a window, the
RETAINED mode just keeps a buffer as large as the window in the background.
This eliminates the problem of having to alloc/dealloc many small pieces
of backup storage for a window as another is dragged in front of it.
Otherwise, though, this mode is equivalent to Amiga's SMART_REFRESH, from
a programming standpoint --- the programmer doesn't have to do any work 
for assuring consistency of window contents.

Ali Ozer, NeXT Developer Support
aozer@NeXT.com