Re: Aborting display. Is this possible?

[Eli Zaretskii]

> Date: Mon, 20 Oct 2014 18:57:57 +0000
> From: Alan Mackenzie <address@hidden>
> Cc: address@hidden
> 
> On a PageDown, Emacs needs to do font-locking just to work out how far
> awy the next page is, like David said.  There is a comment in
> window_scroll_line_based: "Fvertical_motion enters redisplay, which can
> trigger fontification...".  This is the killer: scrolling a screen of
> xdisp.c is taking, on average, ~0.09s, the bulk of this time being
> fontification, whereas the key events are coming in every ~0.03s.
> Some way has to be found to scroll with only every third screen (at most)
> getting font-locked.

window_scroll_line_based is not relevant to GUI frames, only to
text-mode frames.  And window_scroll_pixel_based does not call
vertical-motion.

Also, "enters redisplay" needs to be taken with a grain of salt here.
The reference is to display "simulation", whereby Emacs proceeds
through buffer text line after line, computing the metrics of the
characters as it goes (and invoking fontification functions if
needed), but doesn't store the results in glyph matrices and doesn't
proceed to redrawing based on that.  So it's only partial redisplay.
The full redisplay will be done later, after the scrolling command did
its part, and Emacs is back in the command loop with no available
input.

> If every glyph were assumed to be the same size, the calculation of the
> window-start position for the current scroll operation would be _much_
> faster: display would still have to account for text lines overflowing
> screen lines, and invisible text, and so on, 

Yes, but we've lost that paradise when we introduced variable-font
support in Emacs 21.

> So, how about the following strategy: when the (new) variable
> `face-instead-of-fontifying' is bound to a face, AND the input queue is
> non-empty (or, perhaps, very non-empty), the appropriate subroutine of
> window-scroll should deem characters without a `face' (or `fontified' ?)
> property to have face `face-instead-of-fontifying'.
> 
> This should empty the input queue pretty quickly, enabling a current
> buffer portion to get displayed frequently enough.

This would mean we will sometimes wind up in the wrong place after
scroll.  IOW, you are sacrificing correctness on behalf of some
(questionable for now) speedup.  I say ""questionable" because it's
not clear to me that using just one fixed face will significantly
speed up the process of painstakingly moving through text line by
line.

> But in the default situation (redisplay-dont-pause is non-nil), once the
> calculation of the glyph matrix has begun, the redrawing necessarily
> takes place.

Yes, once.  After that, if input events come in faster than Emacs can
process them, you again get a frozen outdated window.

There isn't really a good solution for when input comes in faster than
Emacs can process it.

> > Then the same will happen again for the next PageDown key.  The result
> > is a frozen window display, because all the attempts to redisplay are
> > aborted due to input rate that is high enough to preempt redisplay,
> > but not high enough to prevent Emacs from entering redisplay after
> > every (or almost every) PageDown key.  To see more frequent updates
> > that give an illusion of scrolling, we would need a feature that
> > ignores the input availability, or maybe dynamically changes the
> > number of input events that could be ignored when redisplay falls
> > behind.  We don't have such a feature.
> 
> Is this really the case?  Is it not that the font-locking caused by
> scrolling is slow enough, that the input queue is never empty, hence
> redisplay doesn't get a look in?

It eventually gets to that, because some screenfuls need more time to
redisplay.

> > Now, what happens when you release the key?  The input queue is still
> > full of unprocessed PageDown keys.  As I explained above, Emacs will
> > drain the entire input queue before it enters redisplay; thus the long
> > delay you see after releasing the key.
> 
> And each such PageDown key will necessitate full font-locking for its
> never-to-be-displayed screen.

No, not full, only partial.  See above.

> > You want Emacs to "immediately" display the new buffer position, but
> > this is impossible without some code that would quickly scan the input
> > queue, analyze what's there, and "understand" that 100 PageDown
> > keystrokes can be "optimized" by executing a single scroll-up-command
> > with a suitable argument.  IOW, we would need some input preprocessing
> > stage that could "optimize" input by replacing a series of commands
> > with a single command, and do that cheaply.  We don't have such a
> > feature; patches to add it will probably be welcome.
> 
> :-).  If my analysis is right, this wouldn't help.  A single mega-scroll
> would still be font-locking the entire intermediate buffer region.

Again, only partially so.  And please note that scrolling is
inherently at disadvantage here, because it tells Emacs to move N
screen lines up/down, so Emacs must first figure out where that lands
it.  Other commands that move through buffer text, like goto-char,
don't have that problem.