CLIM mail archive
Date: Mon, 21 Oct 1991 15:32 EDT
From: Land Fleming <email@example.com>
Question on Application-Initiated Display Updates
We are writing an application that uses CLIM:UPDATING-OUTPUT
to incrementally redisplay graphics at the request of the user.
We must also redisplay at the request of the application. We have
not found a way to do this short of calling CLIM:REDISPLAY on the
output history for the display pane, which causes the cache test
to be run on every updating-output record in the history.
This is exactly how CLIM:UPDATING-OUTPUT and CLIM:REDISPLAY are intended
to be used.
It would be preferrable to call redisplay only on the output record
for the presentation that has changed.
If you know exactly what has changed, it is better to do an erase
and/or redraw yourself and not use incremental redisplay. Incremental
redisplay is best used when the data that has changed is less well
defined, exactly because it needs to traverse the entire output record
tree. That is how it determines what to redisplay. I sent mail on
this exact subject only a few days ago.
It was found that the cache
test was in fact run when REDISPLAY was called on a lower-level
updating-output record, but the result of the redisplay was simply
the replacement of the presentation's drawing with a blank screen
area; the redrawn presentation does not appear until the next
"read-command" phase of the application main loop. The code for this is
Please carefully reread the documentation on pages 252-254 on the CLIM
documentation (Section 22.5, Using CLIM:UPDATING-OUTPUT). Pay special
attention the the bottom paragraph on page 252. The critical thing is
that you will only get the proper effect when you call CLIM:REDISPLAY on
the "outer" updating-output record.
If you have a bunch of updating-output records that do not overlap each
other, you can also do separate calls to CLIM:UPDATING-OUTPUT for each
of them, and then call CLIM:REDISPLAY on the smaller pieces. This will
only work if the records do not overlap each other.
;;; This command was written only to investigate how system-initiated
;;; redisplay should be done.
;;; The command lets the user select a "node", which is presented as a
;;; box. Written inside the box the text from the NAME slot of the node
;;; (CLOS) object.
;;; The command then changes the text in the name slot to "new name".
;;; The updating output code in the pane display method will redraw the
;;; box with the new name. The goal of this command is to test ways
;;; of running the cache test and the updating code WITHIN the scope
;;; of the command's execution and only on the presentation of the
;;; selected node.
(define-Config-Frames-Command (com-test-application-initiated-update :menu nil :name "test")
((frame 'CONFIG-Frames) (pane t))
(let* ((node (accept 'node)) ; select node object to alter.
(view (get-view node)) ; VIEW holds the node's info on its graphics and presentation.
(presn (presentation view))) ; the presentation record
(setf (name node) '("new name")
*changed-object* node) ; global checked by the cache test.
; The grandparent of the presentation is the output record history.
; When invoked (below), the cache test is run on every "node" in the history.
#||(redisplay (output-record-parent (output-record-parent presn)) pane) ||#
; If only updating-output record containing the presentation of the altered
; object is redisplayed (below) the cache test is run ONLY on that record,
; but the old drawing of the node is simply replaced by a blank space.
(redisplay (output-record-parent presn) pane)
;; accept below only pauses before next read-command so that the results of the
;; application-initiated update can be looked at.
- No Subject
- From: Land Fleming <firstname.lastname@example.org>
Main Index |