Re: Removing redisplay-dont-pause

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

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

>>> 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.
>
> My "analysis" doesn't care what's done when betwen T2 and T3, but yes,
> T2 is the part that's affected by long lines, jit-lock, invisible text,
> whereas T3 is about actual "drawing", so it can be affected by your 1200
> bauds serial line (if you're sufficiently unlucky to be stuck behind
> such a thing).

Yes, I think we have the same model. I've always divided redisplay into
two phases, in my head: (1) glyph generation and (2) update, where
update starts basically when update_frame is called.

> My impression is that, historically, T3 has been on a mostly decreasing
> slope over time, whereas T2 has been on a rather increasing slope.
> So back in Emacs-18, I suspect that T2 was usually dwarfed by T3,
> whereas nowadays it's rather the reverse.

Yes, 100%. T3 started to matter less and less during the 90s, and I'd
say it isn't a problem at all nowadays. (I don't even know where slow
serial connections have to be used today, or why. And USB 2 has already
something like 420 Mbits/s, IIRC.)

>>> - 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.
>
> That's my understanding as well.
> But the change in hardware performance has made it so that in the
> `direct_output_for_insert` case nowadays T is almost never > T1+T2+T3,
> which is why we could remove that optimization.

Yes I think that change was the Right Thing, because it reduces
complexity.

(BTW, there is a third part of the slow terminal story that I haven't
seen mentioned yet, and which I think might be a candidate for removal:
"scrolling". If that were no longer done, all the hocus pocus around
frame-based redisplay could go. Just saying; it would be larger change.)