🚀 go-pugleaf

In article <1004@apple.UUCP> lsr@apple.UUCP (Larry Rosenstein) writes:
>In article <981@apple.UUCP> lsr@apple.UUCP (Larry Rosenstein) writes:
>>
>>I don't think the problem is with the CopyBits itself.  I have done large
>>CopyBits with no problems (although this was using srcCopy mode, which
>>might be a special case).  The only reference to a 3K limit I can recall is
>>in the Tech Note about MacDraw's picture format.
>
>Someone here pointed out that the 3K reference is in Inside Macintosh (p.
>I-188).  
>
>However, the rule cannot be a strict one.  For example, the Toolbox itself
>does not follow it to the letter.  When you move a window, the Window
>Manager does one CopyBits, regardless of the screen size.  Again, this is
>using srcCopy mode, so perhaps the stack is not used in that particular
>case.
>
>This is a case where Inside Macintosh (or a Tech Note) needs to be more
>explicit about what the stack is used for, so programmers can decide if the
>warning applies to their applications.
>
>I agree that QuickDraw should handle the boundary conditions better (ie,
>without bombing), but I still would like to know what's going on inside (in
>order to do optimizations, for example).
>

Actually, I got the impression that the 3K convention was only necessary
for recorded pictures that would make their way to the scrap.  The reason
behind this is so that any application receiving a picture from the scrap
could guarantee being able to play it if there was at least 3K of stack
space available.

						_emt