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

Previous Next

Full log

Message #62 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: Sun, 16 Mar 2025 21:13:43 +0100

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

>  Could you please try if the attached change works for you (without your patch)?
>
> I was just about to send you log output that showed seemingly random
> values in glyph::frame. You beat me to it.

👍

> This patch appears to fix the problem for me, thank you.

Thanks.

> Is this the only place that they need to be initialized? Was it more
> than glyph::frame that was uninitialized (and was that problematic)?

adjust_glyph_matrix is the only place where these glyph allocations
happen, for window-systems. For completeness, let be just say that
glyphs matrices on ttys function differently. And the whole struct
glyphs in a glyph row were uninitialized because they are allocated via
C's realloc. I don't think this being uninitialized was a problem
before, the problem was only the combination with my assumption that the
memory was zeroed. Don't know where that assumption came from. Maybe
I've misread them, or maybe it's just that I hate leaving memory
uninitialized in general and assumed I wouldn't have done it there. No
idea.

> For my own edification, while logging GLYPH_EQUAL_P, I noticed that
> it's invoked frequently for windows/buffers that are not visible. As
> in, while a hidden vterm buffer is accumulating log output and I only
> have a single stationary buffer visible, I see a flood of log
> messages. Is this expected? It may very well be, I just don't know
> much about the rendering pipeline.

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?

Does that also happen when you use something else than vterm, say M-x
shell or M-x eshell?

Previous Next

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