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: 3071 bytes --]

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öllmann <gerd.moellmann@gmail.com>,
> >       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
-- 
*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: 7149 bytes --]