[mcclim-devel] performance of incremental redisplay

[Robert Strandh]

Andy Hefner writes:
 > 
 > To clarify, I imagined setting the coordinates slot of the bounding
 > rectangle to nil as a signal that the bounding rectangle needs to be
 > recomputed. Recompute-extent-for-changed-child can set the slot to nil
 > rather than immediately recomputing the bounding rectangle, and
 > bounding-rectangle* checks for the nil case and can call
 > tree-recompute-extent itself, saving the value in the slot (until the
 > next change that invalidates it). That way the bounding rectangle is
 > only computed when it is needed, and moving/deleting a number of
 > records does not cause it to be recomputed each time only to be
 > discarded.

This sounds like a good idea, and easy to implement.

 > > The second type of application is more likely to move or delete output
 > > records, that makes it necessary to go through all output records to
 > > determine the bounding rectangle.  For this type of application it
 > > would just be easier to compute the bounding rectangle at the end of
 > > the command loop.
 > 
 > Can you elaborate on when and for what records recomputing of bounding
 > rectangles would be supressed? Formatting utilities such as
 > surrounding-output-with-border and the table formatter require correct
 > bounding rectangles for their contained output, the process of
 > producing which may at some point require a call to
 > tree-recompute-extent. Restricting this to the topmost
 > (stream-output-history) record would be safer and sufficient for some
 > applications, but others may encounter the same problems deeper in the
 > output tree.

I haven't thought this through completely, but it seems to me that
even table formatting only needs to be computed right before the
output is to be replayed.  What I am suggesting is to suppress  all
such computations and just go through the entire tree once, right
before replay.  Doing that would have to invoke the table-formatting
code, of course.  But again, I don't know for sure that it will work.  

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------