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

Incremental Redisplay Performance

    Date: Tue, 3 Mar 1992 13:07 EST
    From: will taylor <taylor@CHARON.arc.nasa.gov>

	Date: Tue, 3 Mar 1992 08:33 PST
	From: Scott McKay <SWM@SAPSUCKER.SCRC.Symbolics.COM>

	    Date: Mon, 2 Mar 1992 21:33 EST
	    From: will taylor <taylor@charon.arc.nasa.gov>
	
	    A typical redisplay using this technique takes less than a second, while the default
	    redisplay took about 8 seconds (for a 50 node graph).

	    This experience reinforces my hope that CLIM 2.0's implementation and documentation
	    will place more emphasis on incremental redisplay performance -- with the default 
	    redisplay functionality my UI was just about unusable.  With my modificaitons the 
	    UI demonstrates the advertised claims of CLIM.

	***New message.  I made a mistake in the code I supplied.  Sorry.***

	This reply is just meant to provide a few more bits of information.
	Please don't think that I am in any way trying to defend the terrible
	performance of CLIM's incremental redisplay.

	Here is a kludgy patch that implements it.  I have not tested this in
	CLIM 1.0, just in CLIM 1.1.  Use :INCREMENTAL-REDISPLAY '(T :CHECK-OVERLAPPING NIL)
	in your pane.

    Thanks for your detailed response -- I hope that it will be typical of the future
    documentation of CLIM's incremental redisplay.

    Will CLIM 1.1 correct the extreme slowness of changing layouts in CLIM 1.0?  I went
    to my own redisplay in that case as well, by creating multiple windows using

You'll have to characterize this better.  The layout changing in
applications I have seen (or written) is quite speedy, at least on
Genera, because "bit save" arrays are used.

    (defmethod MAKE-OVERLAY-WINDOW-STREAM ((frame APPLICATION-FRAME) &key pane-to-overlay
					   default-text-style window-class (scroll-bars :both)
					   (borders t))
      "return window stream located over pane-to-overlay -- not in frame layout"
      (let* ((parent (frame-top-level-window frame))
	     (input-buffer (stream-input-buffer parent)))
	(multiple-value-bind (left top right bottom)
	    (bounding-rectangle* pane-to-overlay)
	  (open-window-stream :parent parent
			      :left left :top top :right right :bottom bottom
			      :input-buffer input-buffer
			      :default-text-style default-text-style
			      :scroll-bars scroll-bars
			      :borders borders
			      :window-class window-class))))

    which occupy the same frame coordinates and then using (window-expose pane) to
    expose the pane which belonged to the currently selected layout.  Apparently there is
    a (REDISPLAY-FRAME-PANE frame pane :force-p t) done on each pane on a newly selected
    layout whether or not the pane is common to the previous layout and whether or not
    the pane has changed.

Hmm, I wonder if the speedups are later than pure CLIM 1.0.  In the
CLIM's I use (admittedly more recent than yours :-), the forced
redisplay is not done on panes that are known to be "initialized".

    When is CLIM 1.1 to be expected?

It varies from vendor to vendor, but all of Lucid, Franz, and Symbolics
are presently doing QA on their CLIM 1.1 releases (although I think
Lucid is calling it CLIM 1.0).

    ==> Will Taylor
References:
Main Index | Thread Index