GNU bug report logs - #61667
29.0.60; Failure to redisplay

Previous Next

Package: emacs;

Reported by: Dmitry Gutov <dgutov <at> yandex.ru>

Date: Tue, 21 Feb 2023 02:55:01 UTC

Severity: normal

Found in version 29.0.60

Full log


Message #326 received at 61667 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: luangruo <at> yahoo.com, 61667 <at> debbugs.gnu.org, gregory <at> heytings.org
Subject: Re: bug#61667: 29.0.60; Failure to redisplay
Date: Sun, 26 Feb 2023 15:44:30 +0200
> Date: Sun, 26 Feb 2023 15:21:40 +0200
> Cc: luangruo <at> yahoo.com, 61667 <at> debbugs.gnu.org, gregory <at> heytings.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> So I mean the delay between me either
> 
> - Pressing 'a' in one scenario (the 'emacs -Q ...' one)
> - Or pressing 'C-x b xas RET' (using Ido completion with my config)
> 
> and the buffer's text being displayed.

OK, thanks.

So maybe to make it crystal clear this is not an Emacs problem, we
should measure the time taken by these two scenarios, with and without
double buffering, from the time Emacs starts and until Emacs sends the
XFlush to the X server.  If the times are approximately the same, and
don't go anywhere near the delays you see, then the delay is not our
problem.

Po Lu, can you help Dmitry identify the place where we call XFlush
after we finish updating the frame and add such a code there?  To
avoid this measurement affecting the delay itself, as we saw with
printfs and trace-redisplay, the timings should be sent via pipe to a
file, not to the screen.




This bug report was last modified 1 year and 62 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.