[mcclim-devel] incremental redisplay slowness and local patches

[Christophe Rhodes]

pw at snoopy.mv.com (Paul Werkowski) writes:

>> 
>> This, however, uses a scary clim-internals internal symbol.  That's
>> fine up to a point, but it would be better from our point of view if
>> there were a way of doing this in a documented way; is there a
>> spec-blessed way of having a custom incremental-redisplay method
>> called?  Alternatively, can climi::window-stream be documented and
>> exported?  Any other ideas?
>
> I have not tried this myself, but there is the
> :record-type keyword to updating-output where you
> can supply your own class of output-record. Then
> redisplay-output-record on what that returns should
> do what you want. No?

Sadly not, I think.  (This was basically our first try).

The problem with this solution is that it's not the redisplay part
that is the time sink in our application, it is computing the region
to replay overlapping records in.  In DEFMETHOD INCREMENTAL-REDISPLAY,
the relevant snippet is
   (let ((res +nowhere+))
     (loop for (r) in erase-overlapping do (setf res (region-union res r)))
     (loop for (r) in move-overlapping do (setf res (region-union res r)))
     (replay history stream res))
which computes the precise region to replay the history over.

Unfortunately, this precise region computation is extremely expensive
in our case, which typically has many many disjoint moved and erased
records.  Our modification is to do
  (setf res (bounding-rectangle (region-union res r)))
which scales linearly with the number of records in erase-overlapping
and move-overlapping, rather than some ghastly factor as in the
default code (and similarly is linear in the replay, rather than again
some ghastly factor when computing whether a record intersects this
highly-complex region); however, this means we need to specialize
INCREMENTAL-REDISPLAY itself, which does not have an output-record
argument.

Cheers,

Christophe