Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!deccrl!news.crl.dec.com!nntpd.lkg.dec.com!ryn.mro4.dec.com!cals.enet.dec.com!deselms
From: deselms@cals.enet.dec.com (Jim DeSelms)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Different way to redraw windows?
Message-ID: <4738@ryn.mro4.dec.com>
Date: 8 May 91 12:05:06 GMT
Sender: guest@ryn.mro4.dec.com
Organization: Digital Equipment Corporation
Lines: 34


In article <1991May7.002959.9701@umiami.ir.miami.edu>, dweisman@umiami.ir.miami.edu (Ordinary Man) writes...
> 
>When you have stuff in a window on the screen, and you cover it with another 
>window, what happens to the bits of memory that were obscured by the covering 
>window? If the memory occupied by 2 windows is separate and contiguous, then 
>shouldn't the memory of the obscured window remain intact? If so, why can you 
>redraw based on that memory? 

However, each window's bits are NOT separate; when you draw in a window, it
is simply mapped to the screen, and not to some private location in memory.

>On a similar note, why can't you implement the 
>redrawing of windows like the Menu Manager handles the redrawing of bits 
>obscured by a menu when you pull it down?

You could do this...  when you want to draw in a window, draw to an
offscreen bitmap, and then copy the changed bits into your on-screen window.
Then when you get an update event, you would just have to recopy the bits.

Why is this not a common practice?  (I'm guessing...)
1) It takes memory.
2) It takes more time when initially drawing because of the extra step of
   copying the bits.
3) It will often give you a LESS efficient update, because sometimes you don't
   have much, or anything, in your window that needs to be redrawn.
4) Whatever anyone else can think of...

This technique is probably pretty useful when your window has a lot of objects
and takes a long time to update the usual way.

Have fun!

- Jim