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: Fri, 10 Apr 2020 17:34:57 +0300
> 
> 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?

> As we've discussed with Stefan, the implementation is likely the reason.

That sounds like a request to stop interfering with the discussion
between you and Stefan.

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

> And I'd hesitate to recommend it to anyone even to deal with
> performance problems.

Not sure why would you hesitate.

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

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