[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: animate incredibly slow compared to 21.3
From: |
Kim F. Storm |
Subject: |
Re: animate incredibly slow compared to 21.3 |
Date: |
Fri, 11 Mar 2005 16:03:53 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
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
- 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, 2005/03/11
- Re: animate incredibly slow compared to 21.3,
Kim F. Storm <=
- 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
- Re: animate incredibly slow compared to 21.3, Jan D., 2005/03/12