Re: animate incredibly slow compared to 21.3

Myabe this is what Emacs should do, create a pixmap, do its drawing there, and then XCopyArea it to the window when done. Why do you think Emacs should do this? What benefit would it provide? I can't see any. It reduces/eliminates flicker during redraw. But if the problem can be solved

Re: animate incredibly slow compared to 21.3

On Sat, 12 Mar 2005 06:13:40 +0100, Jan D. [EMAIL PROTECTED] wrote: Myabe this is what Emacs should do, create a pixmap, do its drawing there, and then XCopyArea it to the window when done. Emacs already does this for images. It is not hard to implement, just replace the X window in all X calls

Re: animate incredibly slow compared to 21.3

On Sat, 12 Mar 2005 12:40:36 +0100, Jan D. [EMAIL PROTECTED] wrote: If a better scheme is found, there is no point. The main point otherwise would be that the redisplay calculations could be made very simple, almost non-existant. It's a big question whether that true though (much of emacs

Re: animate incredibly slow compared to 21.3

Richard Stallman [EMAIL PROTECTED] 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

Re: animate incredibly slow compared to 21.3

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

Re: animate incredibly slow compared to 21.3

Stefan Monnier [EMAIL PROTECTED] 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

Re: animate incredibly slow compared to 21.3

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

Re: animate incredibly slow compared to 21.3

Stefan Monnier [EMAIL PROTECTED] writes: 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. I see.

Re: animate incredibly slow compared to 21.3

Stefan Monnier [EMAIL PROTECTED] writes: 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. I see. If

Re: animate incredibly slow compared to 21.3

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

Re: animate incredibly slow compared to 21.3

On Fri, 11 Mar 2005 23:33:36 +0100, Kim F. Storm [EMAIL PROTECTED] wrote: I don't know the internals of X, but if done properly, the Xserver updates an internal bitmap and only transfers that to the screen when flushed by Xflush. The historical function of Xflush is to flush the queue of

Re: animate incredibly slow compared to 21.3

Miles Bader [EMAIL PROTECTED] writes: On Wed, 9 Mar 2005 20:24:47 -0600 (CST), Luc Teirlinck [EMAIL PROTECTED] wrote: So why is `next-line' so sub-optimal? It calls line-move. Er, Ok, so then why is line-move so sub-optimal? It might be a bit slower than forward-line, but surely it

Re: animate incredibly slow compared to 21.3

Animate used next-line instead of forward-line. I have fixed that. Performance is now comparable to 21.3, and I even run 22.x without optimizations. Thank you. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org

animate incredibly slow compared to 21.3

Symptoms: Invoke, for instance, M-x animate-birthday-present in 21.3 (and the recent 21.4) the animation is smooth. In a CVS emacs built aftre xasserts were turned back off by default, it's flickery and slow and sometimes stalls entirely before completing the animation. Obviously animate is

Re: animate incredibly slow compared to 21.3

Peter Seibel [EMAIL PROTECTED] writes: M-x animate-birthday-present in 21.3 (and the recent 21.4) the animation is smooth. In a CVS emacs built aftre xasserts were turned back off by default, it's flickery and slow and sometimes stalls entirely before completing the animation. Animate

Re: animate incredibly slow compared to 21.3

[EMAIL PROTECTED] (Kim F. Storm) writes: Peter Seibel [EMAIL PROTECTED] writes: M-x animate-birthday-present in 21.3 (and the recent 21.4) the animation is smooth. In a CVS emacs built aftre xasserts were turned back off by default, it's flickery and slow and sometimes stalls entirely

Re: animate incredibly slow compared to 21.3

Miles Bader wrote: So why is `next-line' so sub-optimal? It calls line-move. Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug