[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61667: 29.0.60; Failure to redisplay
From: |
Eli Zaretskii |
Subject: |
bug#61667: 29.0.60; Failure to redisplay |
Date: |
Fri, 24 Feb 2023 17:08:11 +0200 |
> Date: Fri, 24 Feb 2023 16:12:30 +0200
> Cc: luangruo@yahoo.com, 61667@debbugs.gnu.org, gregory@heytings.org
> From: Dmitry Gutov <dgutov@yandex.ru>
>
> >> - Before this commit: the window title doesn't change, it's always
> >> emacs@hostname. But when I press 'a' (bound to 'find-file' lambda),
> >> there never is a noticeable delay before the window contents change. The
> >> buffer is displayed instantly.
> > How is this consistent with your previous finding that the problem
> > exists in Emacs 25, 26, and 27. The change above is only present in
> > Emacs 28. Does this mean that the problem 100-200ms delay and the
> > original problem are two different problems?
>
> Easy: my configuration contains a customization for frame-title-format.
>
> It's set to
>
> (setq frame-title-format '(buffer-file-name "%f" ("%b")))
>
> All the time I spend bisecting the config I didn't think to change it
> (it's the very first line). And this makes the problem appear with Emacs
> 27 and 26 too.
So the hypothesis now is that changes in the frame's title, which
cause Emacs to update the title by issuing GTK and/or X calls, somehow
cause the problem, is that right?
> > Anyway, if the changes in the frame's title are somehow related to
> > this, their effect is to cause Emacs to call x_set_name_internal to
> > display the new title. Could it be that this function takes such a
> > long time to execute? Or does it have some strange effect on the WM?
>
> My vague (and likely wrong) guess would be that the WM knows it needs
> some update from the Emacs window, gets it from the title bar before
> everything else, and marks the update as completed.
Can you please time that function anyway, if only to make sure the
problem is elsewhere? How much time does it take x_set_name_internal
since its call till it returns, when it actually changes the frame's
title?
- bug#61667: 29.0.60; Failure to redisplay, (continued)
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/24
- bug#61667: 29.0.60; Failure to redisplay, Eli Zaretskii, 2023/02/24
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/24
- bug#61667: 29.0.60; Failure to redisplay, Eli Zaretskii, 2023/02/24
- bug#61667: 29.0.60; Failure to redisplay, Eli Zaretskii, 2023/02/24
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/24
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/24
- bug#61667: 29.0.60; Failure to redisplay, Po Lu, 2023/02/25
- bug#61667: 29.0.60; Failure to redisplay, Eli Zaretskii, 2023/02/24
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/24
- bug#61667: 29.0.60; Failure to redisplay,
Eli Zaretskii <=
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/24
- bug#61667: 29.0.60; Failure to redisplay, Eli Zaretskii, 2023/02/24
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/24
- bug#61667: 29.0.60; Failure to redisplay, Eli Zaretskii, 2023/02/25
- bug#61667: 29.0.60; Failure to redisplay, Po Lu, 2023/02/25
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/25
- bug#61667: 29.0.60; Failure to redisplay, Eli Zaretskii, 2023/02/23
- bug#61667: 29.0.60; Failure to redisplay, Po Lu, 2023/02/23
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/23
- bug#61667: 29.0.60; Failure to redisplay, Po Lu, 2023/02/23