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

Previous Next

Full log

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: Alan Third <alan <at> idiocy.org>, 77039 <at> debbugs.gnu.org
Subject: Re: bug#77039: 31.0.50; Flickering on macOS
Date: Mon, 17 Mar 2025 05:20:11 +0100

Aaron Jensen <aaronjensen <at> gmail.com> writes:

>  That sounds suspicious. So you have one window W displaying some
>  innocuous buffer B, and another vterm buffer V that is not displayed
>  anywhere. The shell in V runs something producing output. That does
>  not change B, and also not something visible in W, including
>  mode-line or such or maybe frame title. And that leads to some
>  redisplay of W?
>
> Yes, all of that is true. I can't say whether or not it leads to a
> redisplay of W, I just know right now that it leads to glyph
> comparisons and somehow that leads to flickering in W, so maybe that's
> enough to infer that it's a redisplay of W.

I think one can say that, yes. The glyph comparisons are done in the
part of redisplay that I call "update" which writes to the screen.

(Looking at redisplay from sufficient height, how it works is like this,
for a window on a window-system frame: It maintains two glyph matrices,
the so-called current and the desired one. The current glyph matrix
corresponds 1:1 to what is currently visible on the screen, and the
desired one represents what should be on the screen. Redisplay builds
the desired one, then compares current and desired matrix, and writes
the difference to the screen. That's of course a gross simplification.
Anyway, the comparison step above is where these "equal macros" come
into play. So we're pretty deep in redisplay, I'd say. BTW, there's a
large comment at the start of xdisp.c which explains it hopefully
a bit better, should you be interested.)

>  Does that also happen when you use something else than vterm, say M-x shell or M-x eshell?
>
> Yes, it happens with shell and term as well

To me that looks as if this shouldn't happen. At least judging from what
I remember from the times of Emacs 21.

Maybe Eli has an idea what could cause this. It might be worth submitting
another bug for this.

>  Now pushed. Thanks for the very helpful hint!
>
> Thank you for the quick fix.
>
> Is it clear to you why the glyph comparison failing would lead to
> flickering, even with double buffering enabled?

Heard about the double-buffering feature the first time yesterday, I
think. I had it in a branch in Emacs 21, but I guess it's not that one
:-). Or IOW, no idea. It might depend on how that's implemented.

Previous Next

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