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: Tue, 30 Aug 2022 10:22:29 -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> <83wnaqugvh.fsf@gnu.org> <83pmghu0o0.fsf@gnu.org> Reply-To: Dmitrii Kuragin Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000098273705e778a090" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23298"; 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 Tue Aug 30 19:59:31 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 1oT5WN-0005uJ-5p for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 30 Aug 2022 19:59:31 +0200 Original-Received: from localhost ([::1]:56080 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oT5WL-0001rM-VC for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 30 Aug 2022 13:59:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55770) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oT4x4-0000Uh-EC for bug-gnu-emacs@gnu.org; Tue, 30 Aug 2022 13:23:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47637) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oT4x3-0006Vz-VD for bug-gnu-emacs@gnu.org; Tue, 30 Aug 2022 13:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oT4x3-0002nW-Nt for bug-gnu-emacs@gnu.org; Tue, 30 Aug 2022 13:23:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitrii Kuragin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Aug 2022 17:23:01 +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.166188016810729 (code B ref 57434); Tue, 30 Aug 2022 17:23:01 +0000 Original-Received: (at 57434) by debbugs.gnu.org; 30 Aug 2022 17:22:48 +0000 Original-Received: from localhost ([127.0.0.1]:37386 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oT4wq-0002mz-1O for submit@debbugs.gnu.org; Tue, 30 Aug 2022 13:22:48 -0400 Original-Received: from mail-yw1-f178.google.com ([209.85.128.178]:45778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oT4wn-0002mk-Vs for 57434@debbugs.gnu.org; Tue, 30 Aug 2022 13:22:46 -0400 Original-Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-33dba2693d0so284429547b3.12 for <57434@debbugs.gnu.org>; Tue, 30 Aug 2022 10:22:45 -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=C7vP0peN/DgppbSp+wDXhnLrJwHK9Shlf/zkWKhffSk=; b=NinLqIx3ZdeFOZoKwUntKnePaBCh34/shcSazZYAR+pfjqX5PKACNv8eurQHU8td/G 2FSfOjACogi8qR3JE67sy3HCR8H09yWQH5ceNS8qpHQFac7Ud3g72JD7nuwqIVsydk7E qbcinZ1OGgatPSJr2zJepUkPM1HJLWWRaZXKQGH7+n3tIVhzTfpSP+r+Gri8cKzSJwcO HcKoXUMM9zqhXg59zUfxq4abOohqhhxv3Me02JeoSM+zWrBPc1vflrbvJ1ZdtwdDNYsQ fI/FN3vLDOS25WYErVRceOatRy62fbJkomxfLPY+E4rTLk7dgIWRBWUjCOf2Jz8MLur5 RX6A== 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=C7vP0peN/DgppbSp+wDXhnLrJwHK9Shlf/zkWKhffSk=; b=6PL38D4GywuJLpV2ViR54q+voSveAqIJKVN1EMoYZwE1xo2x2Pg69bCTKoTNXGoiNP 1Vxyj2Uo30cYphf1kPN/fBXYbE+iA4BO0yOFyMpL+DgRF1wxgC40VDVYaG7ZWzKQm5Ok RMpDuXHMRai7URVi/HQcW2NVqQ32G+bQkOS6PDdEh3PqnJDaFByfB5cSLbieMvB18/oT sZa+za99+Gt81Ni+nHmRkHTTDV9IoHspBzKiAuGMZY6zoc0Z5EXgnA/MmHV1nV3+gG1M zhaSUVx7scNAWRPaQCJWJWxTAEh93SKhysH8kBBFdDx1PsC1NN8cl2TjLqN2xn//yHYB 1WEg== X-Gm-Message-State: ACgBeo0z/BRb+RjTdRm8q1NgRWWR0FjZ9yuFkX+BIGHHgT3/Lxe/SFv4 +qd6vEZPlbGz5xEUWBxLBNJ5OFwkczNmGZEaxxtzzw== X-Google-Smtp-Source: AA6agR7uZIgbwd5+s/qGBHgHUPlIQjC+MeD7NigOHeOCShC3aOUa8oiwhTAq9eKmF4EAytJ4nkYTqO+y7Mx1wRMGfaQ= X-Received: by 2002:a81:9253:0:b0:33b:66fb:9da5 with SMTP id j80-20020a819253000000b0033b66fb9da5mr14613604ywg.331.1661880159941; Tue, 30 Aug 2022 10:22:39 -0700 (PDT) In-Reply-To: <83pmghu0o0.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:241150 Archived-At: --00000000000098273705e778a090 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 30, 2022 at 9:59 AM Eli Zaretskii wrote: > > From: Dmitrii Kuragin > > Date: Tue, 30 Aug 2022 09:34:24 -0700 > > Cc: Gerd M=C3=B6llmann , > > 57434@debbugs.gnu.org > > > > So given all of this, can you tell whether Emacs does TRT here? That > > is: > > > > Sorry, what does TRT mean? > > The Right Thing > Thanks. > > > . are all the capabilities that are supposed to be available for > > these two flags are indeed available? > > > > How can I verify it? > > By looking at all the tput calls we emit during the problematic code, > I guess. > I'd be more than happy to try it, but I am not sure I can do that w/o help. > > > . do we need to check any additional capabilities, which are in fact > > used in the problematic scenario, but not tested as part of > > setting these two flags? > > > > It makes sense to me, but since the output is still correct after the > glitch, doesn't it mean that capabilities work > > correctly? > > The flickering isn't supposed to happen. > Btw, can you figure out which screen lines flicker? Do all of them > flicker, or just some? And if you disable relative line-numbers > (i.e. use absolute line-numbers), do the lines still flicker? all of > them? > w/o relative line number, the problematic code doesn't trigger and there is no flickering. Flickering appears once there is some load on redrawing (line numbers, themes, lh mode, etc...). The line numbers expose that the most. Flickering region is always the same for the same cursor position. I previously messaged it in >>> Flickering is consistent for some specific area. If I scroll between 2 lines, back-and-forth Emacs flickers consistently. So, it flickers consistently at the same area and it correlates with the queue values (window, pos) in scroll.c when the const estimation decides to use insertion instead of writing. See scroll.c:do_direct_scrolling:697. Where can I upload video so you can see the behavior? > > > E.g., Dmitrii, do you have some > > display-related software/driver that has some "optimization" features > > turned on? If so, can you turn them off and try again? > > Did you try looking for such features on your system? > I was looking around and didn't find anything specific. The new M1 Pro has some rendering optimizations, but I tried a different option and it didn't change anything. BTW, I experience quite the same thing as in https://mail.gnu.org/archive/html/help-gnu-emacs/2018-04/msg00304.html --=20 *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. --00000000000098273705e778a090 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Aug 30, 2022 at 9:59= AM Eli Zaretskii <eliz@gnu.org> = wrote:
> From= : Dmitrii Kuragin <kuragin@google.com>
> Date: Tue, 30 Aug 2022 09:34:24 -0700
> Cc: Gerd M=C3=B6llmann <gerd.moellmann@gmail.com>,
>=C2=A0 =C2=A0 =C2=A0 =C2=A057434@debbugs.gnu.org
>
>=C2=A0 So given all of this, can you tell whether Emacs does TRT here?= =C2=A0 That
>=C2=A0 is:
>
> Sorry, what does TRT mean?

The Right Thing
Thanks.=C2=A0

>=C2=A0 =C2=A0 . are all the capabilities that are supposed to be availa= ble for
>=C2=A0 =C2=A0 =C2=A0 these two flags are indeed available?
>
> How can I verify it?

By looking at all the tput calls we emit during the problematic code,
I guess.
I'd be more than happy to try it, but= I am not sure I can do that w/o help.=C2=A0

>=C2=A0 =C2=A0 . do we need to check any additional capabilities, which = are in fact
>=C2=A0 =C2=A0 =C2=A0 used in the problematic scenario, but not tested a= s part of
>=C2=A0 =C2=A0 =C2=A0 setting these two flags?
>
> It makes sense to me, but since the output is still correct after the = glitch, doesn't it mean that capabilities work
> correctly?

The flickering isn't supposed to happen.=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Btw, can you figure out which screen lines flicker?=C2=A0 Do all of them flicker, or just some?=C2=A0 And if you disable relative line-numbers
(i.e. use absolute line-numbers), do the lines still flicker? all of
them?
w/o relative line number, the problematic co= de doesn't trigger and there is no flickering.=C2=A0
<= span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri= f">
Flickering appears once there is some load on = redrawing (line numbers, themes, lh mode, etc...). The line numbers expose = that the most.

Flickering re= gion is always the same for the same cursor position.=C2=A0I pre= viously messaged it in=C2=A0
>>>=C2=A0= Flickering is consis= tent for some specific area. If I scroll between 2 lines, back-and-forth Em= acs flickers consistently.

So, it flickers consist= ently=C2=A0at the same area and it correlates with the queue values (window= , pos) in scroll.c when the const estimation decides to use insertion inste= ad of writing.
See scroll.c:do_direct_scrollin= g:697.

Where can I upload vi= deo so you can see the behavior?
=C2=A0

>=C2=A0 E.g., Dmitrii, do you have some
>=C2=A0 display-related software/driver that has some "optimization= " features
>=C2=A0 turned on?=C2=A0 If so, can you turn them off and try again?

Did you try looking for such features on your system?
= I was looking around and didn't find anything specific. The new M1 = Pro has some rendering optimizations, but I tried a different option and it= didn't change anything.

B= TW, I experience quite the same thing as in https://mail.gnu.org/ar= chive/html/help-gnu-emacs/2018-04/msg00304.html=C2=A0
-= -
*If you get an email from me outs= ide of the 9-5 it is=C2=A0not=C2=A0because I'm always on or expe= ct an immediate response from you; it is because of=C2=A0work flexibility= .=C2=A0=C2=A0Evening and weekend emails are a sign I allocated som= e regular working hours for other things (such as family, gym, friends,...)= .=C2=A0 And I encourage you to feel free to do the same.
=

--00000000000098273705e778a090--