Re: Aborting display. Is this possible?

[Alan Mackenzie]

Hi, Eli.

On Tue, Oct 21, 2014 at 06:35:23PM +0300, Eli Zaretskii wrote:
> > From: Stefan Monnier <address@hidden>
> > Date: Tue, 21 Oct 2014 10:01:43 -0400
> > Cc: address@hidden

[ ... ]

> In any case, the way Alan suggests is not TRT, IMNSHO.  We shouldn't
> be sacrificing display correctness for speed; AFAIR, we never did
> anything like that.  What we did was find and implement optimizations
> that catered to specific use cases that were deemed important enough.
> I see no reason to treat this case differently.

> Another data point is this: in the recent years, I've dealt with any
> number of bug reports that complained about minor inaccuracies in
> scrolling, mostly by fractions of line height or even by a couple of
> pixels.  My interpretation of this is that our users expect accurate
> display, and will not easily tolerate sloppiness.

This is a red herring, surely?  Tiny fractions, visible, of the line
height are totally orthogonal to being one or two lines out (which won't
even be visible) after a "sloppy" user action.

> So I suggest to turn the table and ask: how come fontification of C
> sources is so expensive, and how can we make it faster?

It has got slower as it has become more accurate.  Users have complained
about slight inaccuracies in fontification, too.  Fast enough would mean
speeding it up by a factor of around 5.  I don't think this is
practicable.

A couple of days ago, I even got auto-repeated PageDown to hang in Emacs
LIsp mode.  I can't reproduce that at the moment, though.  But I applied
my timing program to cc-engine.el, and its average time to scroll and
display a screen was 0.018s compared with an auto-repeat rate of 0.024s.
That's not a lot of free play.

> If the Lisp implementation cannot be sped up significantly, let's
> implement some of the code in C.  Or maybe we are should request less
> accurate parsing of the source, at least by default -- e.g., perhaps it
> is not very important to display variables in a face that is different
> from, say, data types?

You're suggesting sacrificing fontification accuracy for scrolling
accuracy?  :-)

> IOW, if the measurements show that redisplay takes 10% of the time,
> let's not try to optimize those 10%, but instead concentrate on the
> 90%.

A very common use case for programming languages is when all the
font-lock-* faces are mono-spaced of equal size.  This might even be the
overwhelming majority of use.  Yet the scrolling/display code makes no
optimisation for this.  In this very common case, it is entirely
unnecessary to fontify bits of buffer to work out how much text would fit
onto the screen we want to scroll over.

The whole point of Jit Lock was that we would only need to fontify the
bits of the buffer currently being displayed.  This was partly so that
mode maintainers could be a bit more relaxed about the speed of
font-locking.  The scenario of auto-repeat on PageDown suggests that the
mechanism wasn't fully thought out.

I still say an optimisation to the scrolling code, where an option could
specify that all faces are of the same size (or should be deemed to be
so) is called for here.

-- 
Alan Mackenzie (Nuremberg, Germany).