GNU bug report logs - #77039
31.0.50; Flickering on macOS

Previous Next

Package: emacs;

Reported by: Aaron Jensen <aaronjensen <at> gmail.com>

Date: Sat, 15 Mar 2025 16:43:01 UTC

Severity: normal

Found in version 31.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
Subject: bug#77039: 31.0.50; Flickering on macOS
Date: Sat, 22 Mar 2025 09:17:08 -0700
[Message part 1 (text/plain, inline)]
On Tue, Mar 18, 2025 at 9:52 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Tue, 18 Mar 2025 15:32:41 +0000
> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, alan <at> idiocy.org, 77039@
> debbugs.gnu.org
>
> Yes, redisplay should be a nop, since the buffer which is modified is not
> displayed.
>
> But Aaron seems to say we keep comparing the glyph matrices of the window
> which is not show, something that should not happen, because we don't call
> update_frame on frames that are not visible.
>
> I tried to explain that I wasn't convinced that it was that, that it could
> have, and even likely was, a redisplay of the currently displayed buffer
> (which is why *it* was flickering). Unless anyone thinks that there is
> reason to investigate further, I'm satisfied with the answer that reading
> process output can cause a comparison of glyphs, which is unlikely to
> result in a redisplay of an unrelated buffer.
>
> Reading process output is not supposed to cause comparison of glyphs if
> the buffer to which process output is directed is not being displayed. So
> if you do see glyphs being compared in that case, we should look into that.
> The only glyphs that could be legitimately compared in that case are those
> on the mode line.
>

In my config, I definitely see matrix comparisons when hidden buffers are
updated. It's row_equal_p and update_text_area that are called in rapid
succession even when the shell buffer is not visible.  I tried disabling
both my tab bar and my header line (I don't use a mode line) and I still
saw it updating.

Here's an example log output, this repeats as quickly as yes emits "y"

dispnew.c:4775
dispnew.c:1295
dispnew.c:1295
dispnew.c:1295
dispnew.c:1295
dispnew.c:1295
dispnew.c:1295
dispnew.c:1295
dispnew.c:4775

I can't reproduce this with emacs -Q, unfortunately. It seems to be have as
you described. Hidden buffers do not cause comparisons.

Aaron
[Message part 2 (text/html, inline)]

This bug report was last modified 114 days ago.

Previous Next


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