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, address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Sun, 12 Apr 2020 05:51:58 +0300
> 
> On 11.04.2020 10:55, Eli Zaretskii wrote:
> 
> >> Maybe the fact that you see updating the highlighting after the text has
> >> been displayed as okay, and I don't. It feels like flickering to me, a
> >> visual aggravation. Thus, if I see that during scrolling, it's also
> >> "flickering".
> > 
> > That's not flickering, at least not in our accepted terminology.
> > Flickering is redrawing of the entire frame, without any changes to
> > the contents.
> 
> Allow me to disagree

I was talking about our terminology.  Disagreeing with accepted
terminology will just increase confusion, as happened here.  I Only
now understand what you mean by that.

> IOW, the scrolling speed-up it offers is limited (but could be enough in 
> optimized builds for most of us, and even for -Og builds of current 
> master), but the the downside it brings is the smallest among all the 
> options we've had discussed here.

In your opinion; mine differs.

> My point above there was rather different: removing features to 
> compensate for a high keyboard repeat rate just doesn't seem like a good 
> solution.

We do remove features in other similar situations, for example in
so-long-mode.

> >> If you go back to my last patch and try it, you might see that both the
> >> default behavior, as well as the new behavior with f-b-i-s on, *look*
> >> more responsive.
> > 
> > Perhaps with optimized builds on your fast machine, they do.  But we
> > are specifically discussing slow systems here.
> 
> Have you tried them? Do they not look more responsive [while scrolling 
> continues] than the default behavior?

Yes.  No.

> >> Ideally,
> >> Emacs should stop scrolling as soon as I release the 'v' key. No matter
> >> how many screenfuls it had managed to scroll through in the meantime.
> > 
> > jit-lock-defer-time satisfies this requirement, at least here, whereas
> > fast-but-imprecise-scrolling doesn't.
> 
> (setq jit-lock-defer-time 0) doesn't satisfy that requirement on my 
> machine with '-Og -g3'.

Don't use zero, use something like 0.05 or 0.1.