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: Mon, 20 Apr 2020 06:27:17 +0300
> 
> >> To do that, need to modify the condition of skipping redisplay.
> > 
> > Adding such a condition would be against Emacs design, which enters
> > redisplay only when Emacs is idle.  As long as Emacs is not idle,
> > redisplay will be skipped, that's how Emacs is designed.
> 
> 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.

> If performing it in full in those cases will take just a little more CPU 
> time, the result might be Emacs that looks more responsive under load, 
> and just as fast.

If you can find a way of reusing that information afterwards (more
than redisplay itself already does), yes.  But AFAIU you are talking
about a thorough redesign of the Emacs display engine.  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.

Of course, if you invoke a command that moves to a place that has no
overlap with the text of the previous screenful, no such optimizations
are possible, unless the new screen has some parts of it that happen
to be identical to the old one (yes, Emacs does that optimization as
well).

> > Nothing else can be kept from the move_it_* phase, because the command
> > that is running might not yet have finished, and so not all of the
> > changes that affect display are known.
> 
> It might be possible to construct some "cache key" that would allow us 
> to check whether the remainder of the command changed something that 
> would affect display. And if it didn't, use the last saved result of 
> move_it_*.

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.

> >> But with that assumption, the extra condition of not skipping redisplay
> >> could be simplified (?) to only checking whether the current screen has
> >> been fontified already (i.e. 'fontified' is non-nil). If it's fontified,
> >> we won't skip redisplay.
> > 
> > I don't think forcing redisplay in the way that you suggest is a good
> > idea, see above.
> 
> Because... it will result in worse performance?

No, because you will fight the design, and the design will fight back.
That's all I can say.  IMO, if we want to make the Emacs display more
efficient, we need to redesign it.