🚀 go-pugleaf

--------


In article <1499@midas.TEK.COM> I wrote:
>2.  I want to do a CopyBits of more than 3K bytes.  I must write a loop to do
>    this.  Why couldn't the toolbox routine include a check for the 3K limit
>    and automatically copy the picture in 3K chunks?  (Or better yet, check
>    how much stack space is available, and optimize the copy for the size of
>    the stack.)

In article <2259@husc6.UUCP> olson@endor.harvard.edu (Eric Olson) replies:
> I'm not the least bit familiar with this.  I regularly do CopyBits on much
> larger bitmaps than 3K.  Perhaps you are talking about the old 3K limit
> on the Scrap?  I (and I think everybody else) ignore that, since it was a
> sort of arbitrary limit in the documentation only, to keep things working
> on 128K Macs.

In article <978@apple.UUCP> han@apple.UUCP (Byron Han) replies:
> You could set your application stack size to be larger at startup.

In article <981@apple.UUCP> lsr@apple.UUCP (Larry Rosenstein) replies:
> 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.
>
> I think it would be a mistake for QuickDraw to decide to do the CopyBits in
> pieces behind the programmer's back.  That could have an unknown affect on
> the application, and is not necessary in some cases.  Quickdraw should,
> however, recover gracefully from a lack of memory when drawing a picture.

I therefore offer the following quote from Inside Mac, Page I-188, as part
of the description of CopyBits (*not* OpenPicture):
"Warning: The source bit map must not occupy more memory than half the
available stack space.  A good rule of thumb is not to copy more than
3K bytes."

Since the application involved (MacScan (TM) from New Image Technology) does
*not* support 64K ROM Macs (no flames please; it requires a SCSI port and
other features available only on MacPlus, Mac SE, and Mac II), I checked
Inside Mac, Page IV-23.  There is *no* reference to the elimination of the
3K restriction in the new ROMs, although I did find there is a precedent in
the new ROMs to gracefully handle limited stack space:
"If you tried to draw a long piece of shadowed text, ...  Now it detects the
potential stack overflow and recurses..."

Incidentally, the reason that MacScan does *not* use a larger application
stack (as Byron suggests) is that I wanted to dedicate as much memory as
possible to the scanned data.  An image scanned at 300 DPI eats up memory
rather quickly.  For this reason, MacScan always creates/reads pictures
directly to/from disk (using custom GetPic/PutPic routines) rather than
memory (as suggested by Byron in the code fragment he supplied).

If it is *really* OK to CopyBits more than 3K bytes under some circumstances,
I would like to see those circumstances documented in a Tech Note.  (Is
temporary stack space required when scaling the bitmap?  Is it required
when the bit alignment of the source and dest bitmaps does not correspond?
Or is it required *only* when copying into or out of a picture definition?)
Without such documentation, what assurance do I as a developer have that I
would *not* get burned by future Macs for doing something contrary to the
advice of Inside Mac (even though it just happens to work correctly on current
products).  (Shame on you, Larry :-) )  Incidentally, I was quite pleased to
be informed that MacScan worked properly on the Mac SE and Mac II even though
I had never used either of those machines.  There's certainly something to be
said for following Inside Mac 100%.

I'd like to conclude by thanking Larry and Byron and all those other folks
at Apple for their contributions to Usenet.
 
                            -- Herb Weiner (UUCP:      !tektronix!midas!herbw)
                                           (AppleLink: D0521)