Re: emacs rendering comparisson between emacs23 and emacs26.3

[Eli Zaretskii <eliz@gnu.org>]

> From: Richard Stallman <rms@gnu.org>
> Cc: dgutov@yandex.ru, acm@muc.de, rrandresf@gmail.com,
> 	emacs-devel@gnu.org, rudalics@gmx.at
> Date: Tue, 07 Apr 2020 22:29:30 -0400
> 
> You've written an extremely clear explanation of how fontification and
> scrolling interact.  I'm impressed.

Thanks.  I thought it was important to explain this in so much detail
so that everyone interested in this issue will be on the same page.
What happens in this use case is quite complex, and many people don't
know about these details and therefore are very surprised by some
effects of some changes.

>   > Of course, if fast-but-imprecise-scrolling makes the job of scroll
>   > commands so much easier that Emacs is capable of keeping up with the
>   > keyboard auto-repeat rate, then every screen-full you scroll through
>   > _will_ be displayed, and therefore will be fontified by the calls to
>   > jit-lock from redisplay itself -- and that will again make scrolling
>   > slower.  So fast-but-imprecise-scrolling is most efficient when it
>   > makes scroll commands faster, but not too fast...
> 
> I think that is true, if "faster" and "slower" are interpreted in
> terms of CPU time used.

The CPU time is one major factor, of course.  But not the only one,
because the keyboard auto-repeat rate is a separate factor which can
be controlled and changed independently of the CPU speed.

> But if all of that work, including the fontification of each
> screenful, is so quick that Emacs never falls behind, I think it
> won't seem like "slowness" to the user -- who never has to _wait_
> for it.

That's true, to some extent, but my point was that the elapsed time
will become slower when each screenful is actually displayed while
scrolling.  It isn't an important point, though, just a side comment.