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

[Dmitry Gutov <dgutov@yandex.ru>]

On 10.04.2020 09:47, Eli Zaretskii wrote:
>> Cc: acm@muc.de, rudalics@gmx.at, rrandresf@gmail.com, rms@gnu.org,
>>   emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> 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?

>>> Tradeoffs of what?  You are probably scrolling in a buffer that uses
>>> a single font all over, with fontifications changing only the colors.
>>> While this is a very frequent scenario, it is by no means the only one
>>> Emacs needs to support.  Imagine a buffer where many lines have
>>> characters that become much taller than the default after
>>> fontifications -- in such a buffer fast-but-imprecise-scrolling will
>>> cause you get to the wrong screenful, because it will consider each
>>> character to be displayed with the default face.
>>
>> You will have the wrong screenful, yes. But how wrong exactly? If the
>> user floored C-v, they are not looking for precision.
> 
> 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.

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?

>> As explained in a separate subthread, jit-lock-defer-time=0 has worse
>> side-effects than fast-but-imprecise-scrolling (while including its
>> downside). And I won't even mention values higher than 0.
> 
> Here, it behaves much better.  So maybe some other factors are at work
> in your configuration.  I think we should try making the solid
> solutions work as intended before we look for kludges.  The "normal"
> way of doing something when Emacs is idle is by using an idle timer,
> and that's what jit-lock-defer-time does.  So from my POV it is the
> solution for such problems.

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.

And I'd like for jit-lock-defer-time=0 to work better, so we can remove 
the extra customization option, but it's just not there yet.