bug#57434: 28.1.91; Terminal Emacs Mac OS flickering.

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

> Given our inability to pinpoint the root cause of the problem, and the
> unsolved mystery why on some macOS systems the problem is much more
> prominent than on other macOS systems, I tend to introduce a variable
> that users could set from Lisp to tell Emacs not to use the optimized
> insert/delete-lines algorithm in scroll.c.  Unless some significant
> new ideas or facts emerge in the next day or two, that is.

I guess I've found these facts today, while rummaging in alacritty's
Github project.

Let me mention first that there's quite some flushing and flickering
going on in alacritty's Github issues with all sorts of terminal
applications (tmux, vim, neovim, ...), and on all platforms it runs on
(MS-Windows, GNU/Linux, macOS, ...).

Alacritty is one of a number of terminal emulators using OpenGL with GPU
accelerated framebuffer display.  I must admit that I didn't realize up
to now that such a thing exists.

Framebuffer updates depend on monitor refresh rates, among other things.
One can only update at some given points in time (vsync, vblank, and so
on, I'm not an expert).  That's the typical N frames/second thing one
can find in various contexts.  (And note the different behavior Dmitrii
mentioned on his second monitor.)

Very simplified, what happens is that Alacritty seems to put framebuffer
contents on the screen in the middle of updates sent from terminal
clients.  Which leads to flickering.

For a longer story, see for instance

https://github.com/karlstav/cava/issues/453
https://bytemeta.vip/repo/karlstav/cava/issues/453
https://github.com/alacritty/alacritty/issues/598
https://github.com/kovidgoyal/kitty/issues/4817

and also follow links there.  One screencast there shows vim flickering
in 100% the exact same way (even the colors) that Dmitrii showed with
Emacs :-).

The terminal emulators' proposed solution for this flickering seems to
be that clients support "synchronized updates" as they call it.  That
is, a client sends the terminal emulator begin-update/end-update control
sequences, which the emulator uses to avoid framebuffer updates in the
middle of the update.

Proposed specification:

https://gitlab.com/gnachman/iterm2/-/wikis/synchronized-updates-spec

A number of terminal clients seem to have added this.  Tmux seems to do
it.  Vim I don't know but I'd wager it does when I see the screencast
mentioned above and what Dmitrii showed.  I think other applications do
too, but I haven't digged deeper.

I couldn't find information which terminfo capabilties are supposed to
be used for this, and I don't think it's part of any official
specification.  And I'd like to add that alacritty.org says about itself
"The software is considered to be at a beta level of readiness", so I'm
a bit wary how stable this all is.

In summary, this is for me a very likely candidate for "the root cause".
Someone (tm) should probably take a deeper look at this.

Maybe Dmitrii is up for it?