GNU bug report logs -
#77039
31.0.50; Flickering on macOS
Previous Next
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
Message #74 received at 77039 <at> debbugs.gnu.org (full text, mbox):
> Cc: Alan Third <alan <at> idiocy.org>, 77039 <at> debbugs.gnu.org
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Mon, 17 Mar 2025 05:20:11 +0100
>
> Aaron Jensen <aaronjensen <at> gmail.com> writes:
>
> > 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.
If you are talking about comparing glyph matrices of windows/frames
that are not shown, that shouldn't happen. If it seems to happen, I'd
need a clear recipe where it does, which I could run on GNU/Linux or
MS-Windows, to debug this. Windows that are not displayed don't even
have desired matrices to compare, so I don't think I understand how
this could be possible.
> > 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.
If glyph comparison fails, Emacs will redraw the screen. Whether it
should be visible with double-buffering depends on how that was
implemented on macOS, and what exactly "flickers" as part of
"flickering".
This bug report was last modified 113 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.