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

CLIM query concerning nested presentations

First I'm sorry about the format of my messages I have sent.  Here is my
message resubmitted appropriately.  I keep forgetting that this braindead
UNIX mailtool doesn't insert <returns> when it wraps my sentences around.
Again I'm sorry!

Here is my query concerning CLIM:

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
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))))))))))
Those ellipses represent a unique-id for each output-record, a cache-value
and a cache-test.  My question is given that I wish to selectively add,remove,
and redisplay output-records at each level how can I set up that cache value
to insure that the update progresses down to level of where the change
occurred.  Right now I use a list with as the cache value with each
successive element indicating a change for a level of presentation.
My situation is more of a bottom's up for change rather than the
CLIM assumption of top down (the intensity of changes increases
as these presentations nest deeper).  I want to be sure that if I change
something at the lowest level and somewhere else in my code I redisplay from
a layer above that it carries on thru appropriately.  Is my understanding
incorrect that if the cache-test doesn't fail CLIM will not go on down
from that output-record branch and check out the remaining deeper nested
output-records, or does it go on through just not redrawing that particular
display operation at that level?

Is the redisplay changing these output-records on me such that
my-output-record no longer points to the right one? 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?

I also noticed that CLIM doesn't output my draws in the same order as my
code dictates causing me further headaches.  This might be another reason
that my-output-records aren't in the pane's history and why the above
problem is occuring (How can I force it no not buffer output?).  There is
a lot of changes occuring on my display from the various levels of objects.

Finally, speed has become an issue. There could be a total of 20k presentation
objects total on my display-pane generated from that loop above.  I have also
noticed that if I have some complicated presentations with about 200 or more
atomic drawing operations CLIM takes forever to get it out to the screen?
If I draw it out not as a presentation it takes seconds, whereas if it is
a presentation it may takpresentation to use :single-box.  How can I avoid this?  One of my possible
solutions is that I only present what the user can see on the
display and manually erase and generate presentations?  Any thought on this?

0,,
Main Index | Thread Index