Re: Removing redisplay-dont-pause

[Gerd Möllmann]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> The problem with redisplay hangs keeps surfacing again and again, so I
>>>> do expect that a number of people will try to use it as soon as they
>>>> learn that such variable exists.
>>>
>>> The hangs you have in mind cannot be helped by this variable.
>>
>> I was replying about your example with scrolling. I also tested setting
>> this variable when typing in an Org buffer with many large invisible
>> regions, and setting the variable does help typing speed.
>
> If you can come up with a reproducible recipe, I'd be interested to see
> it, since in most cases, `redisplay-dont-pause == nil` tends to make
> things worse, IME.
>
> The way I think about it is as follows:
>
> Assume the incoming events come every T seconds and take T1 seconds to
> run, and the subsequent redisplay takes time T2+T3 (where T2 is the time
> in the middle where `redisplay-dont-pause` is consulted).

I think you meant to say that T3 is the phase at the end where
redisplay-dont-pause is checked, the update phase that writes to the
screen. T2 would then be the phase where the glyphs are produced.

>
> Then you have the following scenarios:
>
> - If T > T1+T2+T3, then all is well.
> - If T < T1, then we plain and simply can't keep up at all, the
>   redisplay is just not run at all and incoming events keep accumulating
>   as we fall ever further behind the incoming events until the incoming
>   events stop (at which point Emacs will only refresh its redisplay
>   after it has finally caught up with the buffered input).

The direct_output_for_insert optimization was though for that, ensuring
that at least the line one types in is made visible on the screen.

This comes from a time where 1200 or 2400 baud connections existed, like
my first CompuServe connection in the 80s :-). That's ca, 300 bytes max.
for 2400 baud. And a 80x25 screen has 2000 bytes. So, T3 could be much
larger than T2, and my explanation for the fact that input was not
checked during T2: it's not where the problem was.

> - If T1 < T < T1 + T2, then Emacs will keep up with the input (i.e. when
>   the events stop coming, the display is refreshed more or less
>   instantly) but with `redisplay-dont-pause` set to nil it will not
>   refresh the display at all until the incoming events stop because
>   every time it tries to redisplay it gets interrupted by some
>   new input.
>   If OTOH `redisplay-dont-pause` is set to t, then instead of aborting
>   the redisplay, we finish it which slows us down (gets us a bit further
>   behind the flow of input), but does give feedback to the user, and
>   for the next few inputs we'll simply perform no redisplay at all until
>   we caught up with the input, at which point we will again perform
>   a redisplay, so in the end we get a redisplay after every N events
>   where N = (T2 + T3) / (T - T1).
> - If T1 + T2 < T < T1 + T2+ T3, the difference between the settings of
>   `redisplay-dont-pause` is smaller (in both cases, the display is
>   refreshed every once in a while), but there will still be fewer
>   redisplays when `redisplay-dont-pause` is nil because we waste time
>   starting some redisplays which we later abort.
>
> Of course, reality is more complex (e.g. the time T2 is not a constant,
> e.g. it can occasionally be proportional to the number of events since
> the last redisplay), but at least in my tests where we scroll down
> a buffer with a high repeat rate, the behavior matched that naïve model
> closely enough.
>
>
>         Stefan

Agree, and I'd also be interested when exactly redisplay-dont-pause nil
makes a difference today.