From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitrii Kuragin via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#57434: 28.1.91; Terminal Emacs Mac OS flickering. Date: Wed, 31 Aug 2022 10:11:00 -0700 Message-ID: References: <83edx1znjl.fsf@gnu.org> <83czclzms4.fsf@gnu.org> <83ler7vx3o.fsf@gnu.org> <838rn6x4h2.fsf@gnu.org> <834jxux3kd.fsf@gnu.org> <831qsyx2lr.fsf@gnu.org> <142be6aa-f25f-fad2-5597-6e02b0e3e4f6@gmail.com> <8335dcu0sg.fsf@gnu.org> <83ler4s76z.fsf@gnu.org> Reply-To: Dmitrii Kuragin Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000006e929d05e78c953a" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22539"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Gerd =?UTF-8?Q?M=C3=B6llmann?= , 57434@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Aug 31 19:12:40 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oTRGX-0005gK-9P for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 31 Aug 2022 19:12:37 +0200 Original-Received: from localhost ([::1]:43628 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oTRGW-0006hQ-1X for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 31 Aug 2022 13:12:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46992) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oTRFz-0006eF-Ff for bug-gnu-emacs@gnu.org; Wed, 31 Aug 2022 13:12:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50625) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oTRFz-00016z-04 for bug-gnu-emacs@gnu.org; Wed, 31 Aug 2022 13:12:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oTRFy-0002Xu-J3 for bug-gnu-emacs@gnu.org; Wed, 31 Aug 2022 13:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitrii Kuragin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 31 Aug 2022 17:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57434 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 57434-submit@debbugs.gnu.org id=B57434.16619658819736 (code B ref 57434); Wed, 31 Aug 2022 17:12:02 +0000 Original-Received: (at 57434) by debbugs.gnu.org; 31 Aug 2022 17:11:21 +0000 Original-Received: from localhost ([127.0.0.1]:40374 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oTRFI-0002Wy-IA for submit@debbugs.gnu.org; Wed, 31 Aug 2022 13:11:21 -0400 Original-Received: from mail-yb1-f176.google.com ([209.85.219.176]:41829) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oTRFG-0002Wl-GF for 57434@debbugs.gnu.org; Wed, 31 Aug 2022 13:11:19 -0400 Original-Received: by mail-yb1-f176.google.com with SMTP id 130so5095513ybw.8 for <57434@debbugs.gnu.org>; Wed, 31 Aug 2022 10:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=/gkdyGYiFxaYRDWPTpzYVIQg3UQ2fKBo+0OKYzCIQLo=; b=MJDSziMa+1pfNHbF8rrwdFOZCJtmRDI20CvKxYOdNiGIIWCewxOoU5P6jLcP4Z+kZa FqG0K7t7VhcV0bC1CMPMfxFlBQtClnbBkeLInOhs4le+9losqzpLfLins7j51LLLcBzQ f99+o2G//KihNYSzJ5PCarZ8/POZ4d5K8szhsRx/fuv/IrHAbqAzfmRT08ND0U1Pt3KI C2LxyH+1nyc82GWeZO5OhvCNA4hxnn7Ioc+wtI/RlBdpi5Wm3PVQnxuQqYLou3knGnzW a97fysomZMMvWUyYTZEPQNrZMwRb4TBGmJ89Be3nXZOZwgQmtd//DeFgGrFYm2kL8NS4 OVjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=/gkdyGYiFxaYRDWPTpzYVIQg3UQ2fKBo+0OKYzCIQLo=; b=TcUn91MRL8Cd8DWW2puCHXeG7cwC/M4MlISmW+6oNofEGB6npxB+7Qs/P57Qb1laPq qMlnjkVMVNBQqBNQ3Z+sdvSU0B6VX9A6cNnzvwOR/4EZJ81Zc10ol9/YSNDrSOLsGB5i bysNHUnBFBDNf6wczNzWM5wWqJS3BytJ7VdKo/O2j2nnuiYQDXfCY8jBs4G3miEho92I XfeL3BMT6aJyryD0rpe6v97W2rbzH509TA7aR/c0pXmgxofrNBE0UO2IwYHNGxS7t99+ TcMntB8ecRsmp/Rl0f5wwyuwoY7kaDfuFngiiqUNKCfwdisxvR2K61yeaRuTVbQ7Hhz6 OdIg== X-Gm-Message-State: ACgBeo070+BK6aWSF/6q18lsYesxtSPvJOSNNnSYBrdUOg2OHeNV44vU jDANFRZOKVzzuctW1C4YWR56E6UJDEYFIsXjgymf8A== X-Google-Smtp-Source: AA6agR6WjF2F91m/452TC/EZm138F6N47UNBpoaTZ6XnpwojTRYqrDiuuTVK2XUY7KVEGn5JhvVk+BaejWBnAFNHoWw= X-Received: by 2002:a25:2183:0:b0:69c:116e:270c with SMTP id h125-20020a252183000000b0069c116e270cmr10678765ybh.40.1661965871995; Wed, 31 Aug 2022 10:11:11 -0700 (PDT) In-Reply-To: <83ler4s76z.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:241213 Archived-At: --0000000000006e929d05e78c953a Content-Type: text/plain; charset="UTF-8" On Wed, Aug 31, 2022 at 9:34 AM Eli Zaretskii wrote: > > From: Dmitrii Kuragin > > Date: Wed, 31 Aug 2022 09:21:00 -0700 > > Cc: Eli Zaretskii , 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 . 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. --0000000000006e929d05e78c953a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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 htt= ps://youtu.be/51EbX6bNP0M
> And here's a video how smooth vim works in the same setup: http= s://youtu.be/newP7XEA610
>
> So, it is definitely not the terminal or Mac OS problem.

That's a wrong conclusion, AFAIU.=C2=A0 By "terminal or macOS prob= lem" 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.=C2=A0 That vim doesn't show this flickering tel= ls
us nothing: it might well be that vim doesn't use these terminal
commands.=C2=A0 After all, if we disable the use of those terminal commands=
in Emacs, like you already tried, the flickering disappears.=C2=A0 So by the same logic we could conclude that there's no problem at all.
Exactly, b= ut it basically works for me. Which is what I need :) =C2= =A0


> Additionally, I want to say that now I see the problem even when I con= nect 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?=C2=A0 It's the same Emacs using the same algorith= ms
to decide which terminal commands to use in each case.
Probably, it is caused by slowness of SSH=C2=A0and/or and m= y misunderstanding of the terminal=C2=A0capabilities, 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 th= e emacs pointing is in an unsynced state with
> terminal frequency?

I don't see how this can happen.=C2=A0 Emacs outputs commands basically= one
after the other, so their execution should be at the terminal's speed.<= br>
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 a= m looking into `do_scrolling`).=C2=A0

And my assumption is that we c= leared 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 redra= ws it again and we see what we needed to see.
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">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:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (FRAME_TERMCAP_P (f))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Flush out every so many= lines.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Also flush ou= t if likely to have more than 1k buffered
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0otherwise.=C2= =A0 =C2=A0I'm told that some telnet connections get
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0really screwe= d by more than 1k output at once.=C2=A0 */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 FILE *display_output =3D F= RAME_TTY (f)->output;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (display_output)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ptrdiff_t ou= tq =3D __fpending (display_output);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (outq >= ; 900
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 || (outq > 20 && ((i - 1) % preempt_count =3D=3D 0)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fflus= h (display_output);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

So maybe it's worthwhile to see if playing with the 900 figure here
helps in any way.=C2=A0 Or maybe __fpending doesn't work well on macOS?=
I tried bigger/smaller and delete the condition compl= etely, it didn't help....=C2=A0

Also, I want to point out that `baud-rate` work= s and reduces part of the flickering and improves the situation overall. bu= t `tty->line_ins_del_ok =3D 0;` fixes it completely.

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">I can try to add a new variable to configure/override the behavior.=C2=A0=



--
*If you get an email from me outside of the 9-5 it is=C2=A0not=C2= =A0because I'm always on or expect an immediate response from you; it i= s because of=C2=A0work flexibility.=C2=A0=C2=A0Evening and weeke= nd emails are a sign I allocated some regular working hours for other thing= s (such as family, gym, friends,...).=C2=A0 And I encourage you to feel fre= e to do the same.

<= /div>

--0000000000006e929d05e78c953a--