[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE-Official Bug with NewGWorld
- To: INFO-MACL@CAMBRIDGE.APPLE.COM
- Subject: RE-Official Bug with NewGWorld
- From: D0966@AppleLink.Apple.COM (Newpoint Microsmiths,Wakefield,PRT)
- Date: 15 Feb 91 04:09 GMT
- Cc: MCW@RICE.EDU
> From: hughes@aristotle.ils.nwu.edu (Lucian Hughes)
> Subject: Official Bug with Calling NewGWorld in MACL?
> Message-Id: <9102142144.AA20639@aristotle.ils.nwu.edu>
> To: info-macl@cambridge.apple.com, info-macl@cambridge.apple.com
> I'm working on calling the new QD32 Graphic World traps. I couldn't get
> them to be called in MACL, and finally wrote a C file that ff-called them
> to
> get at them (I note that this problem is discussed in what I call below)).
> Now I just noticed in a message you'all sent out some time ago a report
> of a bug in calling NewGWorld from MACL on a MacIIci (ONLY??!!!, I have
> an fx.). Could the patch be sent to me...
Lucian,
There wasn't any patch for this, just a work-around.
In older ROM based 32-bit QuickDraw, NewGWorld would crash if we passed it a
boundsRect which didn't intersect any GDevice while passing 0 for the depth,
indicating that we wanted it to use the maximum depth of any GDevice
intersecting boundsRect. NewGWorld uses GetMaxDevice to search for that
deepest GDevice, and GetMaxDevice returns nil if no GDevice intersects the
rectangle, but NewGWorld never checks it before it starts using it. Kaboom. I
believe I read that this was fixed in newer versions of QD32, but we still
check the rectangle before passing it to NewGWorld (calling GetMaxDevice
ourselves.) A code excerpt which illustrates this follows. Note that this is
(was) only required if passing 0 for pixelDepth, and it wasn't specific to
MACL.
(rlet ((gr :Rect))
(local-to-global-rect rect-to-copy gr)
;;
;; 32-bit QD crashes (on IIci) if the global rectangle passed to
;; NewGWorld doesn't intersect any screen, so check it first
;;
(if (_getmaxdevice :ptr gr :ptr)
(setq offscreen-gworld (make-new-g-world gr))
... else forget it
As a postscript, I believe our code is now smart enough not to get this far
in the first place.
Regards,
Chris Wakefield