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

[Dmitry Gutov]

Hi Eli,

You have addressed only about 30% of my previous email.

I'll have refer to the remaining 70% anyway.

On 09.04.2020 10:46, Eli Zaretskii wrote:
> > 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.

You will have the wrong screenful, yes. But how wrong exactly? If the 
user floored C-v, they are not looking for precision. That's my main 
justification for the approach (a) presented in that last patch, and 
it's the aspect that the said patch improves: instead of having 
imprecise scrolling always, they only have that when input arrives too fast.

> > -  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.

These are all rough patches. I'm more interested in a discussion than in 
a rubber-stamp. And I'd be surprised if fast-but-imprecise-scrolling has 
a significant number of users yet.

> More generally, I don't think I see how even this proposal makes
> something clearly better.

There were two different proposals in that email. And one general 
feature request.

That patch was for (a). I'm inclined to prefer (b), even though the 
implementation is dirtier. See attached patch that switches between (a) 
and (b) based on the value of fast-but-imprecise-scrolling. The (b) 
behavior becomes the default.

Curiously, I think that this patch demonstrates that while 
fast-but-imprecise-scrolling makes scrolling faster (a), the result 
looks less responsive than the (new) default behavior (b). And that one 
looks more responsive than the current one.

Neither of them deals with the backed-up input queue, alas (#2).

> 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?

As explained in a separate subthread, jit-lock-defer-time=0 has worse 
side-effects than fast-but-imprecise-scrolling (while including its 
downside). And I won't even mention values higher than 0.

But, of course, if we can make jit-lock-defer-time=0 non-flickery, we 
could recommend that instead of fast-but-imprecise-scrolling=t.

more_responsive_scrolling.diff
Description: Text Data