Re: animate incredibly slow compared to 21.3

[Kim F. Storm]

Richard Stallman <address@hidden> writes:

>     To make reliable judgement about the display state, line-move must 
>     call sit-for which does redisplay.
>
> That is a really bad problem.  

IMO, it is not too bad -- line-move is primarily (solely?) for
interactive use, so redisplay will happen after the command
anyway.

>                                We need to redesign this.
> In the past, functions such as compute-motion did the job.
> But they have not yet been upgraded to handle computations
> involving variabled width fonts, images, etc.

The problem is not motion as such, but to know whether the
resulting position of point is on a partially visible
line, so vscroll may be needed.

>
> That has been in etc/TODO for many years, but nobody has done
> it.  We need this!

IMO, compute-motion is too cumbersome to use.

A much better approach (IMO) would be to be able to
use sit-for to update the internal state, but without
actually updating the display  (sort of generating the
desired matrix without updating the current matrix;
then code could just assume the display is up-to-date
already).

On the surface, this may be rather tricky as the
desired matrix is only built temporarily, and all
external code references the current matrix.

But what about this (simple) idea:

Provide a function update-display-state which does
_everything_ in redisplay, except doing Xflush (or
similar for other platforms).   Then the user
display is not updated visually with a possible
premature result.

The Xflush will be performed on next normal redisplay
or by calling sit-for etc.

-- 
Kim F. Storm <address@hidden> http://www.cua.dk