jnh@ecemwl.ncsu.edu (Joseph N. Hall) (06/21/89)
Does the 3K-byte suggested restriction for CopyBits (mentioned in IM I) still apply? Does any such "restriction" still apply? Obviously, even a large menu requires more than 3K of cached bitmap underneath; is there any advice on what the limits on the maximum size of a CopyBits transfer ought to be? The whole screen? Whatever will fit on the stack? Pardon me if the answer appears in some Tech Note somewhere, but I don't have a complete set at the moment ...
tim@hoptoad.uucp (Tim Maroney) (06/22/89)
In article <3224@ncsuvx.ncsu.edu> jnh@ecemwl.UUCP (Joseph N. Hall) writes: >Does the 3K-byte suggested restriction for CopyBits (mentioned in IM I) >still apply? Does any such "restriction" still apply? Obviously, even >a large menu requires more than 3K of cached bitmap underneath; is there >any advice on what the limits on the maximum size of a CopyBits transfer >ought to be? The whole screen? Whatever will fit on the stack? I have it on fairly good authority that what happens in CopyBits is that each row gets pushed onto the stack. therefore, it is not so much the total size of the bitmap, but the width, that determines the safety. If you do a MacPaint file bitmap complete, that's safe, because the bitmap is narrow despite being over 50K. On the other hand, if you do a single row that stretches from here to Cleveland, then you could be in big trouble from the stack sniffer. Very wide bitmaps should be broken up into narrower ones to do CopyBits. You should be able to do this by twiddling the source and destination rectangles. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934 "I slept with Faith, and found a corpse in my arms on awaking; I drank and danced all night with Doubt, and found her a virgin in the morning." -- Aleister Crowley, THE BOOK OF LIES
trebor@biar.UUCP (Robert J Woodhead) (06/22/89)
In article <7731@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <3224@ncsuvx.ncsu.edu> jnh@ecemwl.UUCP (Joseph N. Hall) writes: >>Does the 3K-byte suggested restriction for CopyBits (mentioned in IM I) >>still apply? >I have it on fairly good authority that what happens in CopyBits is >that each row gets pushed onto the stack. therefore, it is not so much >the total size of the bitmap, but the width, that determines the >safety. According to something I read many moons ago: The 3K limit applies only on 64k ROMS. Later ROMS (and perhaps System Files) have had QuickDraw patched so that it detects situations where a QD operation will potentially causes a Stack Heap crash, and ``subdivides'' the operation into 2 or more subcalls so as to reduce the stack requirements.-- (^;-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-;^) Robert J Woodhead, Biar Games, Inc. !uunet!biar!trebor | trebor@biar.UUCP ``I can read your mind - right now, you're thinking I'm full of it...''
earleh@eleazar.dartmouth.edu (Earle R. Horton) (06/23/89)
In article <669@biar.UUCP> trebor@biar.UUCP (Robert J Woodhead) writes: >In article <7731@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >>In article <3224@ncsuvx.ncsu.edu> jnh@ecemwl.UUCP (Joseph N. Hall) writes: >>>Does the 3K-byte suggested restriction for CopyBits (mentioned in IM I) >>>still apply? >>I have it on fairly good authority that what happens in CopyBits is >>that each row gets pushed onto the stack. therefore, it is not so much >>the total size of the bitmap, but the width, that determines the >>safety. > >According to something I read many moons ago: > >The 3K limit applies only on 64k ROMS. Later ROMS (and perhaps System Files) >have had QuickDraw patched so that it detects situations where a QD operation >will potentially causes a Stack Heap crash, and ``subdivides'' the operation >into 2 or more subcalls so as to reduce the stack requirements.-- This may be obvious to some, but remember that you can always configure your application to have more or less than the default stack space by using the SetApplLimit() trap call. If you use more, then from what Robert says you would get better performance from operations that have enough stack space to be done in one step. If you don't have an assembler handy, then you could do something like this in MPW C: #define STACKSIZE 20480L /* Or whatever you want. */ main() { int foo,bar; char *heaplimit; /* Last-declared auto variable. */ heaplimit = (char *) (&heaplimit) - STACKSIZE; SetApplLimit(heaplimit); /* * You now have roughly 20k of stack space to play with. */ MaxApplZone(); /* If you need heap space, too. */ /* * The rest of the program is left as an exercise for the reader. */ This technique is better than using the CurStackBase low memory global because it accounts for whatever auto variables are used by main() and its caller. Earle R. Horton "People forget how fast you did a job, but they remember how well you did it." Salada Tag Lines