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

CLIM incremental redisplay question

    Date: Mon, 14 Oct 1991 17:49 EDT
    From: Curt Eggemeyer <curt@eraserhead.jpl.nasa.gov>

Everybody, please state clearly what platform you are using CLIM on.

If you really have 20k objects, you shouldn't use redisplay.  The
performance will kill you.

You should not simply discard CLIM's presentation type stuff out of
hand.  Instead, you should implement your own class of output history,
and use that as the output history for the window with 20k objects in
it.  For example, quadtrees and kD trees will certainly have better
performance than CLIM's coordinate sorted sets when there are hundreds
or thousands of overlapping objects.

If you need more support on how to implement a new class of output
history, you should contact support people at your CLIM vendor.

    In my CLIM 1.0 application I have objects that consist of multi-level
    presentation displayer types of object.  Each object in each layer holds a list
    of pointers to inferior lower level objects (which may also have pointers to
    other lower level objects. All of these levels are simultaneously displaying the
    appropriate graphical information on the screen. ie:  In CLIM style their
    display form from the top level is (they are cached and uniquely identified but
    I'm ignoring that to shorten the example.  Also they hold pointers to their
    respective output-records):

    (updating-output (display-pane)
      (loop for i in top-level-obj-list do
	(setf (my-output-record i)   ;generic accessing method to point to record
	      (updating-output (display-pane ...)
		(with-output-as-presentation (:stream display-pane :object i)
		   (draw-something i)
		   (loop for j in list-of-sub-objects do
		     (setf (my-output-record j)
			   (updating-output (display-pane ...)
			    (with-output-as-presentation
			      (:stream display-pane :object j)
			      (draw-them j)
		     (loop for k in list-of-sub-sub-objects do
			(setf (my-output-record k)
			      (updating-output (display-pane ...)
				 (with-output-as-presentation
				    (:stream display-pane :object k)
				    (draw-each-lowest-level-thing k))))))))))

    Each layer of objects may change by removal and addition of more sub-level
    objects and each object in each layer may change internally (and graphically).
    I want to be able to selectively redisplay, add & erase children records or
    their respective parents from any level and have that automatically get carried
    on down into lower children levels as I thought CLIM would do.  CLIM seems to
    change the records on me without letting me know about it so for example if I
    tell an object from list-of-sub-objects to redisplay its output-record it says
    it doesn't exist in the output-record history tree.  What gives?  

What is probably happening is that you and CLIM are changing each
other's data structures without either of you notifying the other.
Incremental redisplay has license to create new output records as it
sees fit, and indeed the present implementation relies on this.  This is
another reason for not using incremental redisplay.

								      I also noticed
    that CLIM doesn't output my draws in the same order as my code dictates causing
    me further headaches 

Incremental redisplay tries to preserve ordering, but coordinate sorted
set output records can break down with lots of heavily overlapped output.

			 (How can I force it no not buffer output?)  

What platform?
								     Also I
    selectively add and remove branches from the output history from other locations
    in my code (Do I have to contain all of my display stuff within these
    updating-output record forms?).  Finally, speed has become an issue. There could
    be up to 20k presentation objects total on my display-pane.  I'm trying to keep
    display speed up while utilizing the presentation mechanism for my application's
    accept loop.  Should I consider trashing it and tracking the mouse and faking
    presentations on my own?  Any suggestions?

See above.

About incremental redisplay: the principal use of incremental redisplay
is when you have a medium amount of output that is changing dynamically,
and it is hard for the application to characterize exactly how the
display will change from one pass to the next.  For example, the "Peek"
utility under Genera is a good candidate for redisplay.  When you have a
lot of output, incremental redisplay will break down, because it has to
examine each output record to see if it has potentially changed, and
regenerate the output if it has changed.  If you have an application
that *knows* what has changed and there is a lot of output, it is better
to do the redisplay yourself by doing the appropriate erases, moves, and
redraws.  For example, even a simple graphic editor that operates on a
"current selection" is best off avoiding the use of redisplay because
each graphic editor command knows exactly what needs to be redrawn.

0,,
References:
Main Index | Thread Index