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

[Dmitry Gutov <dgutov@yandex.ru>]

On 11.04.2020 16:45, Stefan Monnier wrote:
>> Perhaps the answer is the same as why I do see mostly fontified screenfuls
>> while scrolling, even with jit-lock-defer-time=0.  Like... idle timers manage
>> to run from time to time?
> 
> That's possible, but if so, I think it might be a bug in itself.

Any suggestions for debugging it?

FWIW, it happens with 'emacs -Q' here.

>> Similarly, I usually don't see a flicker right after visiting a file.
>> Only sometimes.  Do you?
> 
> I can't remember seeing a delayed highlight when visiting a file, no.
> [ Tho I'm not completely sure which config you're thinking of.
>    I assume you're talking about (setq jit-lock-defer-time 0).  ]

Yes. Shouldn't it happen, if we follow the same logic?

>>> That's one of the main advantages of the way
>>> `fast-but-imprecise-scrolling` works: it doesn't lie about having
>>> fontified that chunk.
>> Is there a downside to that strategy?
>> What would happen if jit-lock didn't apply the 'defer' value in this case?
> 
> Not sure what would happen, but it would mean jit-lock's
> fontification-function doesn't hold its end of the bargain with the redisplay.
> Maybe it would cause jit-lock to be called right back on the next
> character?

But it seems to work all right during "simulated" redisplay in 
scroll_command, doesn't it? When we bind fontifications-functions to nil 
(with f-b-i-s enabled). Or does that work fine only because there are no 
fontification functions to call?

>> The result is I see a lot more unfontified screenfuls when scrolling (which
>> is a minus), but scrolling is even faster now (but it was fast with previous
>> patches or f-b-i-s already). Further, it almost certainly suffers from the
>> same same problem that makes fast-but-imprecise-scrolling apparently
>> unsuitable for being a default (loss of precision).
> 
> Normally, input_was_pending should be the same during scroll than during
> the subsequent redisplay, so there should not be any loss of precision, no.

No, the same loss of precision as associated with f-b-i-s. Since 
font-lock won't occur while scrolling, whatever different-sized fonts, 
etc, that could be applied, won't be. So the scrolling positions will be 
imprecise.

>> But I wonder if anyone would want to scroll this quickly when they can't
>> read this fast anyway (or even briefly scan through the contents of the
>> windows that fly by).
> 
> I think we should aim for "scrolling always keeps up".  When
> I lean on C-v, it's often because I'm looking for something which I can
> recognize visually, so when display is skipped it defeats the purpose.
> Of course, sometimes the "something which I can recognize" needs to be
> font-locked to be recognizable in which case skipping jit-lock may also
> defeat the purpose (unless it had been font-locked earlier), but still,
> something is better than nothing.

The other way to do this can be:

a) make sure redisplay is never skipped while scrolling,
b) somehow throttle input events in this kind of situations.

How to define "this kind of sitiations" is an open question thus far, 
but it should be possible to to differentiate between the user hitting 
the keys and the user holding them, at least in graphical environments.