dweisman@umiami.ir.miami.edu (Ordinary Man) (05/07/91)
I have an interesting question from one of my professors here... 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? 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? Now that's a fast redraw! :-) Please excuse the clumsy wording of this question as it was somewhat hard to put into words from my professor. Thanks, Dan /-------------------------------------------------------------------------\ | Dan Weisman - University of Miami - Florida | || || || || | |--------------------------------------------------| || || ||\ /|| | | INTERNET -----> dweisman@umiami.IR.Miami.edu | || || || | || | | BITNET -----> dweisman@umiami | ||||||| || | || | |-------------------------------------------------------------------------| | "The more I get to see, the less I understand..." - Triumph | \_________________________________________________________________________/
deselms@cals.enet.dec.com (Jim DeSelms) (05/08/91)
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
francis@zahpod.uchicago.edu (05/09/91)
In article <4738@ryn.mro4.dec.com> deselms@cals.enet.dec.com (Jim DeSelms) writes: >In article <1991May7.002959.9701@umiami.ir.miami.edu>, dweisman@umiami.ir.miami.edu (Ordinary Man) writes... >>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...) >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. You just use the updateRgn as your mask for CopyBits. -- /============================================================================\ | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | What do you get if you multiply 6 by 9? | | francis@zaphod.uchicago.edu | --Ultimate Question | \============================================================================/
fry@zariski.harvard.edu (David Fry) (05/09/91)
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? The bits are REPLACED by the bits of 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? The memory for all things on the screen is in one piece. It maintains the image of everything on the screen separate from what's in windows. That is, there is no memory of what is in windows. That said, there are two exceptions. The first is when the programmer puts a Picture handle containing a "snapshot" of the window's contents into the WindowRecord, which will force the Window Manager to update the window's appearance whenever necessary. You could call that remembering the bits of the window, but it's not really. The other exception, of course, is when the programmer maintains a copy of the window in an offscreen buffer for fast drawing. Then the "bits" of the window are stored elsewhere, but it's not done by the system and each individual program still responds to update events. >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? Now that's a fast redraw! :-) You can and many programmers do. It's just using an offscreen buffer. When you put a menu down, the Menu Manager copies the bits that WILL be obscured to a temporary buffer, if memory permits. When you release the menu, the bits are put back from the buffer. If you are "lucky" enough to be running low on memory sometime, you'll be able to notice that if there isn't enough memory for this, the Menu Manager will instead send update events to all the windows that got obscured and redraw the desktop, a slower technique. MS Word comes to mind. I believe that before a dialog box is put up, they copy the current contents of the window offscreen and use them to redraw the window when the dialog box is dismissed. David Fry fry@math.harvard.EDU Department of Mathematics fry@huma1.bitnet Harvard University ...!harvard!huma1!fry Cambridge, MA 02138
d88-jwa@byse.nada.kth.se (Jon W{tte) (05/09/91)
In article <.edu> francis@zahpod.uchicago.edu writes:
You just use the updateRgn as your mask for CopyBits.
Suppose the screen is 32bits deep, but your bitmap is one bit
deep. Let's say that all the window contains is a filled square.
If you hide the window and then show it again, you're gonna get
an update for _all_ of the window, and copying 1->32 is definately
slower than drawing a square with FillRect. (Let's say the square
is small...)
Now, copy 32->32 is slow enough, even on an fx...
--
Jon W{tte
h+@nada.kth.se
- Power !Ed.Estes@p911.f421.n109.z1.FidoNet.Org (Ed Estes) (05/13/91)
Actually the window manager DOES provide a way of updating windows that's based on an offscreen picture. I agree with your "guess" - the reason most don't is because it take a LOT of memory. Especially when you start dealing with 24 bit color images! --Ed * Origin: The Clone: Macintosh Things - 301-946-8677 (1:109/421.911)