Re: animate incredibly slow compared to 21.3

[Stefan Monnier]

>> 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.

Agreed.

>> 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.

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.

>> 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.

Agreed (see comments in windmove.el, one of the two packages that use
this function; the other being avoid.el, and also the window-buffer-height
function in window.el).

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.
I.e. compute-motion could be made obsolete, in my opinion.

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).

> 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.

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?


        Stefan


--- orig/lisp/window.el
+++ mod/lisp/window.el
@@ -521,20 +521,12 @@
 
 (defun window-buffer-height (window)
   "Return the height (in screen lines) of the buffer that WINDOW is 
displaying."
-  (save-excursion
-    (set-buffer (window-buffer window))
-    (goto-char (point-min))
-    (let ((ignore-final-newline
-           ;; If buffer ends with a newline, ignore it when counting height
-           ;; unless point is after it.
-           (and (not (eobp)) (eq ?\n (char-after (1- (point-max)))))))
-      (+ 1 (nth 2 (compute-motion (point-min)
-                                  '(0 . 0)
-                                  (- (point-max) (if ignore-final-newline 1 0))
-                                  (cons 0 100000000)
-                                  nil
-                                  nil
-                                  window))))))
+  (with-current-buffer (window-buffer window)
+    (count-screen-lines (point-min) (point-max)
+                       ;; If buffer ends with a newline, ignore it when
+                       ;; counting height unless point is after it.
+                       (or (eobp) (not (eq ?\n (char-before (point-max)))))
+                       window)))
 
 (defun count-screen-lines (&optional beg end count-final-newline window)
   "Return the number of screen lines in the region.