CLIM mail archive
[Prev][Next][Index][Thread]

No Subject

    Date: Mon, 21 Oct 1991 15:32 EDT
    From: Land Fleming <fleming@aio.jsc.nasa.gov>

    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
    as follows:

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.
	      (accept 'string)))))





0,,
References:
Main Index | Thread Index