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

spreadsheets & clim

   Date:     Thu, 17 Mar 94 9:40:42 EST
   From: Nichael Cramer <ncramer@BBN.COM>

   >Date: Wed, 16 Mar 1994 19:50-0500
   >From: Jim Aragones <aragones@crd.ge.com>
   >Subject: spreadsheets & clim
   >
   >i've been thinking about implementing some of the functionality of a
   >spreadsheet using clim and was wondering if anyone had been moderately
   >successful.  my simple approach was to use incremental redisplay to
   >accept values in a table.  i've had a very little success - in other
   >words, what i have does what i need, but it's too slow and has lots of
   >nasty quirks.

   I have a spreadsheet/table-editing system that I've been working on for
   some time[*].  My experience is much the same as yours, i.e. that the
   "normal" types of redisplay are too slow by an order of magnitude to be
   useful on all but the most trivial tables.

I have repeatedly used the spreadsheet as a prime example of something
where using CLIM's usual updating-output/redisplay facility is going
to have awful performance.  The update behavior of spreadsheets is
highly constrained, and a very general facility like incremental
redisplay has no way of knowing this.

     [* The original version was written in an early CLIM-0.9.]

   For example one application used the system to display tables that were
   typically on the order of 30 columns by 600-1000 rows.  Doing this in the
   naive, straightfoward way (e.g. formatting-table + incremental redisplay)
   it would take fully a couple of minutes to initially draw the complete
   table and on the order of a full minute to do each incremental update.

   As a result I've built a number of tools to support this work: 

   1] Panes that are clever about displaying _only_ those cells that are
   actually on the screen.  Furthermore there is a win in that --because the
   rectangular, grid-like nature of the cells-- I don't have to worry about
   output-records overlapping and the consequent problems for refresh.  (I
   understand Scott McKay has a special output-record that handles some of the
   grid-like issues, but I've not had a chance to look at it.)

I do have such an output record, but I've never finished it to my
satisfaction.  I am willing to give it out "as is".  I have a few
little examplettes that run many times faster (> 100x) than the naive
use of incremental redisplay.

   2] A "hierarchial" pane-type that allows me to cluster a set of panes
   together as a unit (sort of like the SMBX notion of using a frame as a pane
   which is itself imbedded inside a frame from the good old days).

   3] Some hacks to support multiple, parallel scrolling of several panes in
   synchony. 

   >if you know of anything that might help me, even a commercial clim-based
   >spreadsheet tool, let me know.

   My _hope_ is to put at least some of this in the CLIM-library.  This
   depends on 1] getting my employer's blessing to do this (which I suspect
   won't be much of a problem) and 2] my finding the time to actually do it.
Main Index | Thread Index