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

[Dmitry Gutov]

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: flickering can be localized. We've have 
discussions in the past about stuff flickering around the cursor, for 
example (due to running timers and the absence of double buffering).

In any case, I called it that because, for lower values of the 
delay-time, is feels about about the same, and is similarly annoying.

Better names welcome.

> > And on *very slow* machines, okay, that can be a solution. Even so, a
> > low enough machine might not keep up with scrolling even if font-lock is
> > skipped, so it's not a panacea.
>
> On such slow machines, fast-but-imprecise-scrolling is not a solution,
> either; IME it actually is worse than jit-lock-defer-time.

In doesn't mess with fontification. So the users would lose rather 
little (most of the time) if such fast-but-imprecise-scrolling was 
enabled by default, especially with the proposed improvement.

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.

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.

> > Because it feels like giving up. "Here's a solution, please disregard
> > that it comes with obvious downsides".
>
> What are the alternatives?  If the system is slow, we must cause Emacs
> do less so that it doesn't appear as hanging up.

I agree with "do less", of course.

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

> > None of it deals with keyboard auto-repeat. On the other hand, having
> > input keys fire as fast as they can is not a hard requirement.
>
> Keyboard auto-repeat (or the equivalent repeated turning of the mouse
> wheel) was what started this thread.  Let's not change the subject.

I'm not changing it.

There are two main problems, mentioned from the beginning:

- The user doesn't see what's going on (redisplay stops updating).
- Emacs continues to do something long after the key have been released, 
or the mouse wheel stopped rotating.

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

> > (And there are other commands where such behavior would also be preferable).
>
> Which commands are those?

'undo' and 'backward-delete' come to mind, both of which have repeatable 
bindings in my config. The first one especially can take arbitrary 
amounts of time. 'previous-line' and 'next-line' too (their misbehavior 
is usually unnoticed, but just try (setq scroll-conservatively 1)).

> Are you sure the current discussion about
> jit-lock and its slowdown is relevant for explaining the slowdown of
> those commands?

It would be relevant if we look into other solutions rather than trying 
to speed those commands' execution.