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

[Dmitrii Kuragin via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 4244 bytes --]

On Wed, Aug 31, 2022 at 9:34 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Dmitrii Kuragin <kuragin@google.com>
> > Date: Wed, 31 Aug 2022 09:21:00 -0700
> > Cc: Eli Zaretskii <eliz@gnu.org>, 57434@debbugs.gnu.org
> >
> > And here's one more video of default `baud-rate` vs 1000000
> https://youtu.be/51EbX6bNP0M
> > And here's a video how smooth vim works in the same setup:
> https://youtu.be/newP7XEA610
> >
> > So, it is definitely not the terminal or Mac OS problem.
>
> That's a wrong conclusion, AFAIU.  By "terminal or macOS problem" we
> mean that some terminal commands, like those that insert and delete
> lines in a region of a screen, cause flickering on those systems
> and/or those terminals.  That vim doesn't show this flickering tells
> us nothing: it might well be that vim doesn't use these terminal
> commands.  After all, if we disable the use of those terminal commands
> in Emacs, like you already tried, the flickering disappears.  So by
> the same logic we could conclude that there's no problem at all.
>
Exactly, but it basically works for me. Which is what I need :)


> > Additionally, I want to say that now I see the problem even when I
> connect to a remote linux machine using
> > SSH.
>
> Why did you expect the problem to disappear when you use Emacs via SSH
> on the same terminal?  It's the same Emacs using the same algorithms
> to decide which terminal commands to use in each case.
>
Probably, it is caused by slowness of SSH and/or and my misunderstanding of
the terminal capabilities, but I didn't see the problem when I was
connected to Linux using SSH.

>
> > Could it be that alacritty so fast that it gets into the state when the
> emacs pointing is in an unsynced state with
> > terminal frequency?
>
> I don't see how this can happen.  Emacs outputs commands basically one
> after the other, so their execution should be at the terminal's speed.
>
It also might be caused by my limited knowledge of TTY. But, I see that we
redraw linest not from top to bottom, but actually we try to redraw
different portions of the screen at different times. (I am looking into
`do_scrolling`).

And my assumption is that we cleared some portion of the screen and
prepared it for new contents, but due to unsynced frame rates, the terminal
redraws that partial state. And only then, we add some content in those
empty lines and then the terminal redraws it again and we see what we
needed to see.
Do we always draw frame as a single atomic operation or those things aren't
synchronized at all?


> However, there's one place where we accumulate bytes before flushing
> them: in update_frame_1:
>
>           if (FRAME_TERMCAP_P (f))
>             {
>               /* Flush out every so many lines.
>                  Also flush out if likely to have more than 1k buffered
>                  otherwise.   I'm told that some telnet connections get
>                  really screwed by more than 1k output at once.  */
>               FILE *display_output = FRAME_TTY (f)->output;
>               if (display_output)
>                 {
>                   ptrdiff_t outq = __fpending (display_output);
>                   if (outq > 900
>                       || (outq > 20 && ((i - 1) % preempt_count == 0)))
>                     fflush (display_output);
>                 }
>             }
>
> So maybe it's worthwhile to see if playing with the 900 figure here
> helps in any way.  Or maybe __fpending doesn't work well on macOS?

I tried bigger/smaller and delete the condition completely, it didn't
help....

>
>
Also, I want to point out that `baud-rate` works and reduces part of the
flickering and improves the situation overall. but `tty->line_ins_del_ok =
0;` fixes it completely.

I can try to add a new variable to configure/override the behavior.



-- 
*If you get an email from me outside of the 9-5 it is *not* because I'm
always on or expect an immediate response from you; it is because of work
flexibility
<http://www.inc.com/john-boitnott/how-flexible-hours-can-create-a-better-work-life-balance.html>
.  Evening and weekend emails are a sign I allocated some regular working
hours for other things (such as family, gym, friends,...).  And I encourage
you to feel free to do the same.

[-- Attachment #2: Type: text/html, Size: 7936 bytes --]