llama@eleazar.dartmouth.edu (Joe Francis) (02/05/91)
Take all of this with a grain of salt, as I haved erred before and will err again (and again). In article <231b3679.665550627@fergvax> CS 231 section 2 writes: >Surely there must be an easier way; why >does the Window Manager go out of it's way to nuke my window's portBits? Why >couldn't I somehow say RestorePortbits()? And I'd also like to some drawing >in color. An 8bit deep "full" screen image would take up way too much memory, >something like 170k! As you have unknowingly pointed out, the Window Manager would have had to go out of it's way to save bitmaps of window contents. The original 128K mac clearly did not have room to save 20k or more of hidden window bits. The portbits are stored right where you see them, in the screen buffer (or on a video card for some of the II's). Thus, when they're hidden, they're gone. Traditionally programs have saved window contents for CopyBits "blasting" when they have the memory, and when they run short they purge their off- screen bitmaps and redraw the slow (but memory cheap) way. >Another quick question: IM vol I, p188 warns "The source >bitmap must not occupy more memory than half the available stack space. A good >rule of thumb is not to copy more than 3K bytes." Does this warning still >apply? As I said above, I'm using a full screen window, and with me using my >kludgy way of preserving, I'm CopyBitting about 22k at a time (But just in >case, I set my stack space pretty high). It is my understanding that this limitation is no more. It might be, however, the CopyBits will go faster if it has a stack of twice the copy-bits size. Can anyone confirm? My intuition would also suggest that the stack is only used if the source and destination rects overlap. ---------------------------------------------------------------------------- "Read My Lips: No Nude Texans!" - George Bush clearing up a misunderstanding