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

Re: reducing time overhead of text display (in 1.1)

    Date: Wed, 22 Dec 1993 18:42 EST
    From: Scott McKay <SWM@[128.81.253.18]>

	Date: Wed, 22 Dec 1993 16:38 EST
	From: Bruce R. Miller <miller@cam.nist.gov>

	Leading up to...

	    I get good performance out of CLIM for many things, and rarely resort to
	    what can rightly be called tricks.  My suggestions to "implement your
	    own class of output record" really isn't trick either.  

	It seems to me that I have a prime candidate for this kind of treatment.
	My application has a sort of `outline' pane; Sort of like the lispm's File System Ed.
	There are a list of items with indented sub-items with ...  
	Each can be opened & closed.  Each is a presentation of some sort and
	takes up _exactly_ 1 line of display. [some do have presentations as
	parts, though] 

	Fine, but some items have ~1000 sub-items.  This gets pretty slow for
	redisplay, especially considering at most 20-30 are on the screen at any
	time!

	Finally, I'd like to have some finer control over scrolling.  At times I
	need to make a particular item visible:  open it & it's superiors and
	then scroll the pane to the right place.

	Am I right that this is a natural candidate?  

    This is such a natural candidate, that I already have an implementation
    of it.  It is not completely debugged -- it's got one very mysterious
    fencepost error in it.  Would you like me to send it to you?  If I do,
    you have to promise to send me back any bugfixes and generally useful
    improvements you might make to it...

Bruce and I went through several iterations, resulting in a working
"text scroll" implementation.  We have built on top of it two simple
applications, which will be familiar to anyone who has used Genera: a
simple FSEdit-like program, and a simple Peek-like program.

Bruce also wrote a small benchmark program that shows several ways of
doing the same application.  The benchmark that does exactly what he
describes above using UPDATING-OUTPUT takes about 26 seconds to open a
sub-list of 1000 items, and 7 seconds to close it (on my XL1200).  With
the new substrate, it takes 5 seconds to open the 1000 items the first
time (and .32 seconds thereafter) and .12 seconds to close it -- a
performance improvement of 60x.

We will post this code sometime very soon when a few (very) minor
glitches are worked out.
Follow-Ups:
Main Index | Thread Index