Re: Aborting display. Is this possible?

[Alan Mackenzie]

Hi, Eli.

On Mon, Oct 20, 2014 at 10:24:54PM +0300, Eli Zaretskii wrote:
> > 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.

OK.  But the problem occurs both in GUI and tty.  There'll be some C
function at a deeper level where the GUI and tty cases meet up.  The tty
case is not going to be more difficult to solve than the GUI one.  [ By
the way, it's brilliant how effectively the difference between them has
been abstracted away for elisp programming. ]

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

Yes, I've got that.  But in CC Mode, it's the fontification which takes
most of the time (see also below).

> > 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'd posit that the absolute correctness isn't all that important after an
auto-repeating PageDown.  For an individual PageDown keystroke, the
fontification and scrolling would be done accurately as now.

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

OK: some numbers, on emacs-24 -Q in both cases:

To scroll backwards on a tty with a 64 line window through xdisp.c takes
0.106s per screen (on average).  Doing the same on an already fontified
buffer takes 0.0128s per screen (on average).  It would seem that the
fontification is taking ~87% of the time.  (See the thread "Scrolling
xdisp.c.  Room for optimisation in syntax.c/CC Mode." for details of the
measurement.)

The same on a GUI (in X-Windows on a GNU system, 33 line window):
0.05268s per screen, fresh; 0.00655 per screen, starting fully fontified.
Fontification is taking a similar proportion of the total time.

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

Er, making Emacs process the input faster?

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

I think it gets to that stage very early indeed.

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

I don't see the "above" here.  When I tested the `fontified' property
this morning, EVERY position from point-min to point had been fontified.

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

I still don't see the "partially".  Why wouldn't everything get fontified
again (for the calculations for scrolling, not for display)?

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

Yes.

-- 
Alan Mackenzie (Nuremberg, Germany).