Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!mcnc!decvax!decwrl!labrea!polya!ali
From: ali@polya.STANFORD.EDU (Ali Ozer)
Newsgroups: comp.sys.amiga
Subject: Re: Feeping Creaturism
Message-ID: <2142@polya.STANFORD.EDU>
Date: 12 Mar 88 16:34:43 GMT
References: <8802181921.AA19069@cory.Berkeley.EDU> <682@sandino.quintus.UUCP> <5295@utah-cs.UUCP> <732@nuchat.UUCP> <7599@apple.Apple.Com> <2122@polya.STANFORD.EDU> <1451@csib.csi.UUCP>
Reply-To: ali@polya.UUCP (Ali Ozer)
Organization: Stanford University
Lines: 28

In article <1451@csib.csi.UUCP> jwhitnel@csib.UUCP (Jerry Whitnell) writes:
> ...  I'm not familiar with the Amiga, so I'd like to know how 
>do you as a programmer handle the memory requirments for the bit maps for a 
>large number of windows?  

The only screen which normally gets most crowded with windows is the Workbench
screen (the equivalent of the Finder), but this screen is normally 2-bitplanes
deep, so backups don't create a problem. A program wanting more or less
bitplanes or a different set of colors simply goes out an opens it's own
screen. Thus a game program that can live in low-res but that needs 32 colors
can open a 320x400x5 screen, while a word processor can open a 700x470x1
screen. The user can drag these screens up and down (like blackboards) to
switch between them. Different screens are just different memory blocks (the
system can read scanlines from anywhere in the chip memory), so there is no
problem of backup bitplanes when screens cover eachother. And the normal
windows still remain in the 2-bitplane Workbench screen. Of course, a program
that can live with the Workbench configuration or that needs to open a window
on the Workbench (say a clock program) can still open windows on the Workbench.

>| ... The Mac, on the other hand, lets you open a window real easily, in a
>|few lines of code, but then makes you do all the grunge work at runtime.
>The grunge work, however, is a couple of 100 lines of code that can be
>done once and reused in other applications.  

The problem is, it's 100 lines of code that has to be executed, preferably
many times a second. And by every application that is running.

Ali Ozer, ali@polya.stanford.edu