Re: Scrolling commands and skipping redisplay, was: Re: emacs rendering comparisson between emacs23 and emacs26.3

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden, address@hidden,
>  address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Thu, 9 Apr 2020 03:32:13 +0300
> 
> > 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...
> 
> In my testing with an '-Og -g3' build (from emacs-27; master is much 
> faster with the recent tweaks) it allows for redisplay once every 
> several screenfuls or so. So it seems like a good tradeoff, in those 
> particular conditions.

Tradeoffs of what?  You are probably scrolling in a buffer that uses
a single font all over, with fontifications changing only the colors.
While this is a very frequent scenario, it is by no means the only one
Emacs needs to support.  Imagine a buffer where many lines have
characters that become much taller than the default after
fontifications -- in such a buffer fast-but-imprecise-scrolling will
cause you get to the wrong screenful, because it will consider each
character to be displayed with the default face.

> -  if (whole && Vfast_but_imprecise_scrolling)
> +  if (whole && input_was_pending)
>      specbind (Qfontification_functions, Qnil);

I don't like this, because it's unconditional.  In my view, the
tradeoff proposed by fast-but-imprecise-scrolling is a bad tradeoff,
something I personally will never take, even if Emacs locks up for
many seconds in some situation.  If you suggest to _add_ the
pending-input condition to fast-but-imprecise-scrolling being set,
then I'm okay with that optional behavior being smarter (assuming this
doesn't have downsides we aren't aware of yet), if users of
fast-but-imprecise-scrolling agree with it.

More generally, I don't think I see how even this proposal makes
something clearly better.  We already have jit-lock-defer-time; people
who have slow machines are advised to set that to something like 0.1
or 0.25, and they can have scrolling that is way faster than with
fast-but-imprecise-scrolling (and with the same tradeoff of making
scrolling "imprecise").  Why invent kludges when we already have a
better solution that was there since Emacs 21?