Re: animate incredibly slow compared to 21.3

[Kim F. Storm]

Stefan Monnier <address@hidden> writes:

> To make scrolling (even of images or lines of widely different height)
> reliable, compute-motion would need to pay attention to every display
> element and parameter, including things like frame-local face properties.
>
> So either it re-implements the redisplay or it reuses the redisplay.
>
> I.e. the current code of line-move reuses the result of redisplay, which
> seems to be the best solution.

Agree.

> For both avoid.el and windmove.el, compute-motion is used to get the X/Y
> coordinate of point.  I.e. posn-at-point would be a better choice now.
>
> As for window-buffer-height, the patch below simplifies it by using
> count-screen-lines (which uses vertical-motion) rather than compute-motion.

Seems good to me.

> I.e. compute-motion could be made obsolete, in my opinion.

Agree!!

> OTOH vertical-motion seems to be used more frequently and its behavior is
> similar to compute-motion (it can be used for a buffer that's not currently
> displayed), so maybe there is indeed a need to compute hypothetical display
> behavior (i.e. display behavior of something that is not displayed).

True -- I didn't think about that aspect.  Also, vertical-motion
does pay attention to variable pitch/height, so that's another
reason to use it in favour of compute-motion.

> But maybe it's important to be able to compute the matrix without *ever*
> displaying it.  E.g. in fit-window-to-buffer, count-screen-lines is used to
> decide how to resize the window.
> In the case where the matrix will be displayed sooner or later, I don't
> think it makes much sense to delay the Xflush.  What's the benefit?

I was thinking about the situation where the sit-for in line-move
results in a situation where we would adjust the vscroll, and thus
update the display once more.  I haven't noticed this myself, but
I could envision that may cause flickering.

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