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: Sat, 11 Apr 2020 03:21:52 +0300
> 
> > What else could be the reason of differences between what we see on
> > our respective systems?
> 
> 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.  That's not what happens here: Emacs only redraws the
parts that have non-default colors, and it doesn't redraw the tool
bar, the menu bar, and the mode line (only the line number and the
percent are updated in the mode line).

> > Showing unfontified text _is_ the intended effect of
> > jit-lock-defer-time.  On slow machines, I fail to see how this could
> > be worse than having Emacs hang for many seconds.
> 
> There can be other options.
> 
> 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.

> >> And I'd hesitate to recommend it to anyone even to deal with
> >> performance problems.
> > 
> > Not sure why would you hesitate.
> 
> 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.

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

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

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

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

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