Re: Aborting display. Is this possible?

[Eli Zaretskii]

> Date: Sun, 19 Oct 2014 15:42:55 +0000
> Cc: address@hidden
> From: Alan Mackenzie <address@hidden>
> 
> > That's not what happens.  What does happen is that redisplay _tries_
> > several times to do its job, right after each PageDown keypress, each
> > time starting with the value of point it sees, then abandoning that
> > attempt because input arrives before it could finish.
> 
> So if 35 PageDowns are received in a second, it starts redisplay after
> each and every one.

Yes, unless by the time Emacs finishes processing one PageDown key
there's another one in the keyboard queue.

> How much time does it take before checking for pending input?

It checks for it every cycle through the command loop.  IOW,
"immediately" after the command bound to PageDown finishes, and
control is returned to the main loop.

> Could my problem be that this time is short enough that that no
> intermediate screen has time to display a fragment, but long enough that
> there's a significant pause when the user finally takes her finger of
> PageDown?

It seems like you think Emacs is able to produce only a partial redraw
of the screen; if so, you are wrong: Emacs never does that.  Redisplay
of each window (or maybe even each frame, I don't recall exactly) is
an atomic operation: it is either done completely, or not at all.
Emacs checks for pending input at strategic places, so that you never
see a partially incorrect display.

(Of course, when redisplay-dont-pause is non-nil, as it is by default,
pending input doesn't interrupt redisplay at all.  the above describes
what happens when redisplay-dont-pause is nil.)

As for the user lifting the finger, this is not the problem.
Auto-repeat still sends one key at a time, with some time interval
between the keys.  As long as that interval is long enough for Emacs
to compute the beginning of the window due to PageDown (and how long
could that be?), Emacs will attempt to redisplay before the next
repeated key arrives.

> What is stopping a fragment of each intermediate screen (or of some of
> them) being displayed?  Could it be that the display engine calculates an
> entire screenful of glyphs before it starts displaying them on the
> physical screen?

Emacs first calculates the minimum portion of the screen that needs
redrawing (checking for input several times during this part, and
abandoning redisplay if there's input and redisplay-dont-pause is
nil).  When these calculations are finished, it checks for input one
last time.  If there's no input, or if redisplay-dont-pause is
non-nil, Emacs proceeds to actually drawing the parts that changed,
and redraws all that is needed without any further input checks.
Otherwise, the redisplay cycle is aborted.

This is done for every frame at least, perhaps even for each window (I
don't remember).