Re: Deffering redisplay in COMINT

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> I ran several different configurations trying to identify important
> criteria related to the display of this large block of text.

>        Display |               GUI/X |              Text/NW|
> Truncate-lines |      nil |        t |      nil |         t|
>   ---Filter--- |    ----- |    ----- |    ----- |     -----|
>           BASE |   3:43   |   5:51   |   0:16   |    4:20  |
>             SS |   3:42   |   3:06   |   0:12   |    2:04  |
>            HSC |    N/A   |   0:07   |    N/A   |    0:04  |

From your tests, it seems clear that the problem is always redisplay
time, which is why the extra work of HSC pays off.

I think I can understand the difference between truncate and
non-truncate on a tty (the amount of buffer text redisplay has to
consider (i.e. (- (window-end) (window-start))) when refreshing the
display is larger (proportional to the line lengths) than with
wrap-around).  But I don't understand why we don't see the same impact
in the GUI case.  IOW I really don't understand the "3:42" of SS+GUI
with truncate-lines==nil.  I'd expect it to be *much* lower (like 0:20
or so).

Maybe we could speed it up the 2:04 case with a redisplay optimization that
skips more quickly over the truncated part of the lines (special casing
the "easy common case where there's no before/after-string, no `display'
property, ...").

You could try and tweak the SS code further to reduce the number of
redisplays.  E.g. not only you "wait for a complete line" but you also
"wait for the next second" so the buffer is only redisplayed once
a second.

Or you could try to do something halfway between SS and HSC: instead of
keeping the non-displayed part of lines in a separate buffer (as in
HSC), you do insert them (as in SS) but with an `invisible'
text-property set to t so that the redisplay can (hopefully) skip over
it very quickly.


        Stefan