emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scrolling commands and skipping redisplay, was: Re: emacs rendering


From: Stefan Monnier
Subject: Re: Scrolling commands and skipping redisplay, was: Re: emacs rendering comparisson between emacs23 and emacs26.3
Date: Sat, 11 Apr 2020 09:45:17 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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

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

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

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

> The main plus there being that it *can* keep up with the keyboard's
> repeat rate.

Aha!

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


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]