[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: _DrawPicture



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