CLIM mail archive
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@[18.104.22.168]>
Date: Wed, 22 Dec 1993 16:38 EST
From: Bruce R. Miller <firstname.lastname@example.org>
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
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
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.
Main Index |