[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: animate incredibly slow compared to 21.3
From: |
Stefan Monnier |
Subject: |
Re: animate incredibly slow compared to 21.3 |
Date: |
Fri, 11 Mar 2005 08:36:21 -0500 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
>> 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.
- animate incredibly slow compared to 21.3, Peter Seibel, 2005/03/09
- Re: animate incredibly slow compared to 21.3, Kim F. Storm, 2005/03/09
- Re: animate incredibly slow compared to 21.3, Peter Seibel, 2005/03/09
- Re: animate incredibly slow compared to 21.3, Miles Bader, 2005/03/09
- Re: animate incredibly slow compared to 21.3, Luc Teirlinck, 2005/03/09
- Re: animate incredibly slow compared to 21.3, Miles Bader, 2005/03/09
- Re: animate incredibly slow compared to 21.3, Kim F. Storm, 2005/03/10
- Re: animate incredibly slow compared to 21.3, Richard Stallman, 2005/03/10
- Re: animate incredibly slow compared to 21.3, Kim F. Storm, 2005/03/11
- Re: animate incredibly slow compared to 21.3,
Stefan Monnier <=
- Re: animate incredibly slow compared to 21.3, Kim F. Storm, 2005/03/11
- Re: animate incredibly slow compared to 21.3, Stefan Monnier, 2005/03/11
- Re: animate incredibly slow compared to 21.3, Kim F. Storm, 2005/03/11
- Re: animate incredibly slow compared to 21.3, Jan D., 2005/03/11
- Re: animate incredibly slow compared to 21.3, Miles Bader, 2005/03/11
- Re: animate incredibly slow compared to 21.3, Jan D., 2005/03/12
- Re: animate incredibly slow compared to 21.3, Miles Bader, 2005/03/12
- Re: animate incredibly slow compared to 21.3, Jan D., 2005/03/12
- Re: animate incredibly slow compared to 21.3, Miles Bader, 2005/03/12
- Re: animate incredibly slow compared to 21.3, Stefan Monnier, 2005/03/12