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
> From: Dmitry Gutov <address@hidden>
> Date: Fri, 10 Apr 2020 17:45:43 +0300
> 
> On 10.04.2020 09:47, Eli Zaretskii wrote:
> >> Cc: address@hidden, address@hidden, address@hidden, address@hidden,
> >>   address@hidden
> >> From: Dmitry Gutov <address@hidden>
> >> Date: Fri, 10 Apr 2020 01:17:51 +0300
> >>
> >> You have addressed only about 30% of my previous email.
> > 
> > I don't have anything to say about the rest.
> 
> Not even about the last patch I sent?

What would you like me to say about it?

> > Depends on what you mean by "precision".  They might very well miss
> > some parts of the buffer entirely, i.e. never see them on display.
> > This may or may not be important, depending on the use case.  An
> > editor is not supposed to skip portions of the buffer when scrolling
> > continuously.
> 
> And that's what my last patch helps it avoid doing, by default.

It does?  Then maybe I didn't understand what it does.

> Speaking of the loss of precision, though. You said you'd never make 
> that choice, and yet you recommend the use of jit-lock-defer-time. It 
> has the very same problem, doesn't it?

Yes.  And that's why I personally don't use jit-lock-defer-time even
on slow machines.  But if someone is prepared to pay that price,
jit-lock-defer-time is IMO a better solution because it is much faster
(and also much cleaner, if you ask me).

> When I said "worse", I didn't mean to say "slower", I meant worse in how 
> it looks. Performance-wise, jit-lock-defer-time=0 and 
> fast-but-imprecise-scrolling=t work about the same here.

On my system, jit-lock-defer-time=0.1 is much faster that
fast-but-imprecise-scrolling=t.