pw@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