|
From: | Dmitry Gutov |
Subject: | Re: Scrolling commands and skipping redisplay, was: Re: emacs rendering comparisson between emacs23 and emacs26.3 |
Date: | Thu, 9 Apr 2020 22:30:05 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 |
On 09.04.2020 22:16, Stefan Monnier wrote:
Thanks. I tried it (and mentioned in the parent thread), but it seems like in addition to the downsides of f-b-i-s (imprecise scrolling, which apparently makes it a bad candidate for default behavior) it adds some extra flickering from time to time (I figured because some redisplays occurred before the idle timer had the chance to run). It's not as obvious in an 'emacs -Q' session, but with my custom config it's more apparent. And that flickering occurs the most while I'm flooring C-v.I think the flickering is the direct effect of the defer'd jit-lock:
It's weird, though, that it's not so obvious with the 'emacs -Q' build.
you first see the non-jit-lock'd text and only after that the idle timer runs jit-lock and updates the display accordingly.
And that it happens in the middle of scrolling. All the while C-v is still pressed.
And also: jit-lock-function supposedly has a provision for that sort of circumstances: jit-lock-defer-time=0 specially, doing fontification immediately, as long as input-pending-p=>nil.
Is it possible that the conditions for skipping redisplay might return false while input-pending-p returns t?Very much so, yes: the tests are sufficiently different and the possible circumstances sufficiently varied that it's almost unavoidable. E.g. usually the redisplay is skipped based on the presence of input at the *beginning* of the command, whereas the `jit-lock-defer-time` thingy samples the input later, when jit-lock is called.
The condition for skipping redisplay based in the presence of inputs before and after, to be a tad more accurate. But the difference is there, to be sure.
So thus far fast-but-imprecise-scrolling seems to provide better behavior. I would love to remove that variable, though, and just tell people to use jit-lock-defer-time *if* the jit-lock behavior can be improved.
[Prev in Thread] | Current Thread | [Next in Thread] |