🚀 go-pugleaf

In article <1329@cartan.Berkeley.EDU> lippin@skippy.UUCP (tom lippincott, ..ucbvax!bosco!lippin) writes:
>Recently tecot@apple.UUCP (Ed Tecot) said:
>>In summary, QuickDraw is reentrant, but it's dependency upon the memory
>>manager precludes its use during interrupt time.
>>						_emt
>
>
>Where were you a few months ago when I needed to make use of this?
>I was only writing a prototype of a program, and I figured that
>locking down everything in sight and trying this would be safe enough
>for my purposes.

How can you guarantee this?  Any region call (such as when a window is moved
so that it's visRgn changes) could cause a call to SetHandleSize which may
relocate the block.  I don't know what happens if the block is locked; but
it's not good in any case.

>I had a VBL task doing some drawing; I wanted characters, but would
>settle for lines, or a copybits call.  Meanwhile, the main program
>wanted to draw sometimes.  What happens?  Whenever the main program
>is interrupted while drawing over the cursor, it leaves a cursor image
>lying on the screen.  Fine for drawing pine forests, but not good for much
>else.
>
>I eventually tracked this down to the QD cursor globals getting confused,
>and had the VBL task save and restore them as necessary.  Another
>not-so-good step, but it certainly looks like the calls were *not*
>reentrant.  I hope you're not speaking for Apple on this one.

The cursor code may not be reentrant, but the remainder of QD should be.
If you are drawing at interrupt time, and I don't think you can do any more
than off-screen CopyBits, you probably have to be very careful as not to
get in the way of the cursor.  I personally recommend that you not draw to
the screen at interrupt time; there are clean workarounds to be had.

I still stand by my QuickDraw claims (but not as an Apple Representative).
(I do not consider the cursor code to be QuickDraw)

						_emt