Re: Unfreezing the display during auto-repeated scrolling.

[Alan Mackenzie]

Hello, Stefan.

On Sun, Oct 26, 2014 at 04:42:38PM -0400, Stefan Monnier wrote:
> I'm not sure exactly what to think here.

> I think it is very desirable to try and come up with ways to speed up
> redisplay in cases such as auto-repeated scrolling.

> It seems that Alan's patch has a fairly small impact on the C code (in
> terms of its structure, not necessarily in terms of the end result),
> which is good.

> But even better would be something that has no impact at all on the
> C code.  Of course, I'm biased: I hacked my own defer-lock.el before
> Simon Marshall published his.

> So, I'd be in favor of trying to solve this at the Elisp level, ...

I don't think this is possible.  At least some minimal, finicky changes
will be needed where xdisp.c calls fontification functions.  (See below).

> ... i.e. inside jit-lock.  I think the result might even be better than
> Alan's patch because it should let Emacs keep up with scrolling much
> more easily (tho displaying un-font-locked content while scrolling).

The problem is, _every_ scroll operation into unfontified territory is
calling Fvertical_motion (or worse in the GUI case).  Fvertical_motion
calls start_display calls init_iterator calls reseat calls handle_stop
calls handle_fontified_prop.

At this stage, _nothing_ can stop handle_fontified_prop running
fontification-functions causing the fontification of >=
jit-lock-chunk-size (500) bytes.  Well, my patch stopped this, but
nothing else currently in the system can.

500+ bytes is about a fifth of the 2500 bytes which fit on my 65 line
screen, so fontifying them is going to take ~.017s (see other email
threads for details of these measurements).  My auto-repeat repeat rate
is every 0.024s, leaving 0.007s for other processing if Emacs is going to
keep up.  It can't; 0.007s isn't enough.

The above fontification is happening on _every_ scroll operation, even
though the fontified text is never going to appear on the screen.  The
sole purpose of this fontification is to work out how big (in pixels)
characters are.  And this is in the tty case.

The display code has been optimised for variable sized characters, and
all possibilities of optimising for the very common case of uniform
sized characters has been thrown out the window.  My patch was a way for
a user, in effect, to tell Emacs that his characters are all the same
size.

Something's got to give.

Maybe Eli's suggestion of rewriting scroll-up and scroll-down from
scratch in Elisp could work, but if I'm not mistaken, there's no
infrastructural support for window lines, etc., which doesn't involve
fontification.  This would have to be written.

If movement on a window absolutely requires fontified characters, then
some means will need to be found for the display code to tell jit-lock
HOW MUCH needs fontifying, and for that amount to be much less than 500
bytes in the non-display case.

> What I suggest is to refine jit-lock-defer such that jit-lock is
> deferred if there's input pending.

> I understand there's an underlying problem here, which is that "input
> pending" is something that's not tested reliably.  Maybe we will need to
> try and fix this as well.

As already pointed out, even one jit-lock-chunk-size fontification per
0.024s in C Mode is going to overfill the event queue, and that's with
nothing actually being drawn on the screen.

One might hold that it is unreasonable to expect Emacs to keep up with 42
PageDown's per second with a 65 line window on a mere 2.6 Ghz processor.
I disagree.

One might argue that CC Mode fontification should be speeded up.  Yes, it
should, but it's not ever going to be speeded up by an order of
magnitude.  Even in Emacs Lisp Mode, fontifying and displaying a 65 line
screen averages out at 0.018s, compared with a 0.024s repeat rate.
There's simply no spare processing capacity for frivolous
jit-lock-chunk-size'd fontifications.

Something's got to give.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).