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

Previous Next

Full log

View this message in rfc822 format

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: bug#61667: 29.0.60; Failure to redisplay
Date: Sun, 26 Feb 2023 14:13:51 +0200

> Date: Sun, 26 Feb 2023 13:59:34 +0200
> Cc: gregory <at> heytings.org, luangruo <at> yahoo.com, 61667 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> >    . "emacs -Q", then type 'a' (which visits a file?)
> >    . "emacs" with your configuration, then type "C-x b", which visits a
> >      file
> > 
> > In both cases, you see a delay before the display is updated, right?
> 
> About 1 in 5-10 tries the delay is high enough to be noticeable 
> (200-300ms with -Q and up to 1-2 seconds with my config).
> 
> > So what effect, if any, does the changing vs fixed frame title have on
> > each of these two use cases?
> 
> The delay (which is, physically, always present) becomes never nigh 
> enough to be noticeable.
> 
> Or, in simple terms, disappears.
> 
> > And what effect does disabling
> > double-buffering have on each of these two cases?
> 
> Same effect: delay "disappears".

Thanks, but I still need to insist on more clarity, if possible.

You say "disappears", in quotes, presumably to say that it's still
present but hard to notice?  And before that, you say the delay is
always physically present?  If the delay does not actually disappear,
without any quotes, and is always present, then the frame's title and
double-buffering just make it easier to detect the delay, but don't
affect the delay itself.

I think we must have a clear understanding whether the delay
disappears or just becomes hard to detect.

Previous Next

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