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

[Dmitry Gutov]

On 10.04.2020 18:47, Eli Zaretskii wrote:

> > On 10.04.2020 16:34, Eli Zaretskii wrote:
> > > It doesn't flicker here.  Maybe the double-buffering is the reason?
> >
> > Double-buffering decreases the number of display updates, so it hardly
> > can be the cause of this.
>
> 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".

> > It doesn't flicker while scrolling because it simply shows unfontified
> > screenfuls of code. Which is unacceptable for default behavior.
>
> 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.

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

> > It *does* flicker afterwards (e.g. 0.5 sec after I depress C-v), because
> > that's what deferred jit-lock does: it applies syntax highlighting with
> > a delay.
>
> Highlighting shouldn't flicker; it doesn't here.  It just paints the
> text with colors.  Redisplay is smart enough to redraw on the glass
> only those parts whose colors have changed, and that shouldn't cause
> any flicker.

That's what I call flickering in this particular discussion.

When delay is small (e.g. <= 0.1), the visual effect is closer to what 
we would call flickering traditionally (fast visual changes in display 
where there shouldn't be any). When the delay is larger, the effect is 
somewhat less aggravating, but at the same time the lack of syntax 
highlighting for prolonged times is more obvious. That's like a feature 
breakage.

> > So I type, wait 0.5sec, and syntax highlighting arrives. It's a
> > less-aggravating kind of flicker because of its laid-back pace, but I
> > still wouldn't call it acceptable user experience.
>
> I guess we disagree here.  And I don't really see what better solution
> could be provided, when Emacs is unable to keep up with keyboard
> auto-repeat.  The only solution is to do less, and jit-lock-defer-time
> does just that.

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. And if you go to the first email in this subthread, 
there are justifications for each change there.

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

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

I think that can be implemented, in the GUI Emacs, at least.