Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!oliveb!pyramid!voder!apple!lsr
From: lsr@apple.UUCP
Newsgroups: comp.sys.mac
Subject: Re: What makes programming the Mac difficult?
Message-ID: <1004@apple.UUCP>
Date: Thu, 11-Jun-87 16:52:36 EDT
Article-I.D.: apple.1004
Posted: Thu Jun 11 16:52:36 1987
Date-Received: Sat, 13-Jun-87 09:51:04 EDT
References: <869@apple.UUCP> <1499@midas.TEK.COM> <981@apple.UUCP>
Reply-To: lsr@apple.UUCP (Larry Rosenstein)
Organization: Advanced Technology Group, Apple Computer
Lines: 33

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).

-- 
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.com