[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: _DrawPicture
- To: SHEN@SCHEMER.JPL.NASA.GOV
- Subject: Re: _DrawPicture
- From: STEVE.M@AppleLink.Apple.COM (Aladdin Systems,Steven Mitchell,PRT)
- Date: 04 Jan 92 07:08 GMT
- Cc: INFO-MCL@CAMBRIDGE.APPLE.COM, BILL@CAMBRIDGE.APPLE.COM
To: Sheldon Shen [shen@schemer.Jpl.Nasa.Gov]
cc: info-mcl
Bill St. Clair
From: Steve Mitchell
Date: 1/3/92
Sub: Re: _DrawPicture
IF YOU DON'T CARE ABOUT READING AND DISPLAYING PICTURES, SKIP THIS.
> > On page 88 and 89 of Inside Macintosh V, an example is given
> > to spool a picture from disk. In that example, QuickDraw
> > repeatedly calls GetPICTData, which in turn calls
> > FSRead(globalRef,longCount,dataPtr).
Inside Mac contains very little source code and is not a tutorial. This
example exists to demonstrate that you can display a QuickDraw file of
any size on the screen. If you use this code, every time you redisplay
your picture it gets read in from disk. Almost nobody does this.
> > speed up _DrawPicture by providing a larger buffer?
> Nice idea, but I'm afrad it won't work. The QuickDraw code is
> the one asking for the bytes. It asks for a certain number of
> bytes to be read into a certain area of memory.
Yes, but if you're a typical programmer, you're willing to store the
picture in a picture handle in memory and call _DrawPicture on that
picture handle instead of reading it out of the file every time.
You won't see any improvement on the initial display, but there'll
be a dramatic speedup on all redraws.
If the picture is complex, it may take a long time to draw or even be
larger (more bytes) than the bitmap/pixmap it displays in on the
screen. In that case you can draw the picture into an offscreen
grafport. Then, whenever you want to display it, you blast it onto
the screen with _CopyBits (instead of _DrawPicture). That's why
text scrolling is so fast (note that scrolling doesn't wait for
the next update event, and you generally will when refreshing
your picture).
> The getPicProc field of the QDProcs record is what QuickDraw calls to
> get bytes from a picture.
If you're willing to compromise, you can even speed up the initial reading
of the picture by a factor of 2 to 3. _DrawPicture is being used in the
Inside Mac example to tell a QDProc to parse the picture. If you don't
need to support custom 8-bit color palettes, picture comments and other
niceties, you don't need to use any QDProcs and then you don't need to
call _DrawPicture to read in your picture (in fact, the use of
_DrawPicture in the example as written is totally gratuitous because
it doesn't include any of those QDProcs!). THEN you can let the Mac File
System do the buffering for you...
(require 'mac-file-io) ; high-level File I/O ala Inside Macintosh
;;WARNING: This code lacks some of the functionality of "picture-files.lisp".
(defun get-picture-from-file (pict-pathname &aux pict-handle)
(with-FSOpen-file (pb pict-pathname nil) ;nil => read-only
(let* ((pict-file-length (getEOF pb))
(pict-length (- pict-file-length 512)))
;;(format t "Pict length: ~A ~%" pict-length)
(unless (zerop pict-length)
;can't use offset param of FSRead, that's offset into buffer!:
(setFPos pb 512) ; skip MacDraw header block
;allocate space on a picHandle for the PICTure:
(setf pict-handle (#_NewHandle :check-error pict-length))
(with-dereferenced-handles ((pict-ptr pict-handle))
;read in the (obsolete) size word (which is ignored),
; the picture.picFrame, and the rest of the picture:
(FSRead pb pict-length pict-ptr))
)))
pict-handle)
Of course you now have to call _DrawPicture (or better, draw-picture of
"QuickDraw.lisp") to display the picture in your window. This is generally
done by calling draw-picture in the appropriate view-draw-contents method,
and calling _InvalRect to force it to draw the first time.
_Steve