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

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

    Date: Tue, 25 Jan 1994 12:42 PST
    From: Scott McKay <SWM@stony-brook.scrc.symbolics.com>

	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.

We also have an application that uses incremental redisplay to implement 
this sort of scrolling.  I am interested in using your version, because our's
is too slow when the item count goes up.  I would be willing to help test
and debug your code.
References:
Main Index | Thread Index