[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: start-picture/get-picture question
- To: Rob Browning <firstname.lastname@example.org>, email@example.com
- Subject: Re: start-picture/get-picture question
- From: e@Flavors.COM (Doug Currie, Flavors Technology, Inc.)
- Date: Tue, 25 Jan 1994 13:05:48 -0500
At 4:55 AM 94.01.25 +0000, Rob Browning wrote:
>Here is the function I defined to add graphic items to the window
>(more or less):
>(defmacro append-to-auto-redraw-window (win &rest items)
> `(with-focused-view ,win
> (start-picture ,win)
> (if (contents ,win) (draw-picture ,win (contents ,win)))
> (if (contents ,win) (kill-picture (contents ,win)))
> (setf (contents ,win) (get-picture ,win))))
>1) Isn't it true that unless I add a without-interrupts macro around the
> with-focused-view macro, I'll unintentially capture any
> activation/deactivation or redraw events in the picture while "items"
> are being drawn?
Yes, but... Generally speaking, drawing should only be done in response to
events, and MCL event processing is done inside a without-interrupts. In
other words, in response to an update event, MCL calls window-event ->
window-update-event-handler -> view-draw-contents inside a
>2) However, if I do add the without-interrupts macro, isn't it possible
> that interrupts could be disabled for too long.
I believe that without-interrupts disables MCL's own event processing, but
does not disable the Mac's interrupt handlers. Consequently, adding the
without-interrupts macro around your append-to-auto-redraw-window drawing
code will not cause any data loss from keystrokes or other i/o. The
criterion should be whether or not the application seems responsive enough
given the complexity of graphics you expect to display.
>3) Is there a better way to do this?
The start-picture, get-picture, kill-picture, and draw-picture mechanism
simply records Quickdraw calls into a list (the picture). If the
performance with draw-picture is bad, perhaps you could keep a list of LISP
forms, or closures, which do the drawing. Then simply replay the list when
the window needs to be redrawn. This would eliminate the need for the
explicit without-interrupts (assuming you need to draw outside event
processing at all).