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: Tue, 21 Apr 2020 04:27:19 +0300
> 
> On 20.04.2020 18:16, Eli Zaretskii wrote:
> 
> >> As we've determined, certain commands force redisplay to be performed
> >> anyway (though partially).
> > 
> > That's not redisplay, that's JIT fontification that happens as side
> > effect of redisplay.  It can _also_ happen as side effect of other
> > commands.  But that's not redisplay.
> 
> A certain amount of work that's also part of redisplay.

I suggest to use a common terminology, otherwise we will just confuse
each other.  Let's agree to call "redisplay" only what happens when
Emacs calls one of the two functions: redisplay_internal and
echo_area_display.  OK?  Redisplay calls many functions, including
fontification-functions, but those functions themselves are not to be
called "redisplay", because they don't display anything.

> IIRC posn-at-point also "simulates redisplay". Not sure if scrolling
> commands use it, but others do.

Many commands do, much more than what you mentioned.  If we call all
of them "redisplay" we will completely muddy the waters.

> I'm saying this because my current impression is still that redisplay is 
> skipped sometimes (when Emacs is busy) for performance reasons.

Only if input is available (or if it arrives during redisplay,
assuming you set redisplay-dont-pause to a nil value).

> > It already
> > attempts to reuse every piece of display that can be kept.  For
> > example, if you type C-n on the bottom-most screen line, and you have
> > scroll-conservatively set, the display engine will redraw exactly one
> > screen line, and all the rest will be scrolled (via a direct Xlib
> > call) on the glass, without regenerating the glyphs.
> 
> That's an interesting tidbit. But it seems to also say that redisplay 
> for C-n is usually quite fast.

It is fast.  By default, it will scroll half the window and redraw the
other half (due to recentering).

> > You will see in redisplay_window and its subroutines a lot of code
> > that attempts to do exactly that: figure out what has changed and what
> > hasn't.  You are in effect saying that this must be radically
> > improved, in which case I'd happily agree, but please believe me that
> > it is not a trivial job, certainly not if you want to stay within the
> > current design of the display engine.  You will probably need to
> > design and implement various new fields of the window and buffer
> > objects that will cache more data about the previous state of buffer
> > and display than what they already do, make sure these caches are
> > reset when no longer valid, then build new redisplay optimizations
> > based on those, find the conditions where the optimizations can and
> > cannot be used, etc.
> 
> So I wouldn't be correct to say that the display is only dependent on 
> the current window configuration (shown buffers, window sizes, window 
> scroll positions), buffer text which can be checked via 
> buffer-modified-tick and the overlays which... might have a similar 
> "counter" added?

I don't think I understand the question, but the display engine
already uses the buffer-modified-tick and overlay-modified tick.

> But mode-lines and header-lines aren't amenable to caching, right? That 
> complicates things.

Header line is almost never a problem, it hardly ever changes IME.
Mode line, OTOH, changes almost all the time (at least with its
default format), so I think caching it would be quite futile.  And you
will anyway need to somehow compare the cached value with the updated
one, something that the display engine already does, using the results
of the previous display as "the cache".