bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS

[Aaron Jensen <aaronjensen@gmail.com>]

Would it be worth putting this in Emacs 29 since the RC is out? This
is likely better and so far there are no obvious issues.

Aaron

On Sun, Jul 23, 2023 at 9:01 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> On Sun, Jul 23, 2023 at 7:20 AM Alan Third <alan@idiocy.org> wrote:
> >
> > On Thu, Jul 20, 2023 at 10:02:53PM -0400, Aaron Jensen wrote:
> > >
> > > I've been using this for about a month now and have seen no artifacts:
> > >
> > > diff --git a/src/nsterm.m b/src/nsterm.m
> > > index 78089906752..d23fb650ab8 100644
> > > --- a/src/nsterm.m
> > > +++ b/src/nsterm.m
> > > @@ -2708,9 +2708,6 @@ Hide the window (X11 semantics)
> > >      EmacsView *view = FRAME_NS_VIEW (f);
> > >
> > >      [view copyRect:srcRect to:dest];
> > > -#ifdef NS_IMPL_COCOA
> > > -    [view setNeedsDisplayInRect:destRect];
> > > -#endif
> > >    }
> > >
> > >    unblock_input ();
> > > @@ -10435,7 +10432,7 @@ @implementation EmacsLayer
> > >     cache.  If no free surfaces are found in the cache then a new one
> > >     is created.  */
> > >
> > > -#define CACHE_MAX_SIZE 2
> > > +#define CACHE_MAX_SIZE 1
> > >
> > >  - (id) initWithColorSpace: (CGColorSpaceRef)cs
> > >  {
> > > @@ -10621,7 +10618,7 @@ - (void) display
> > >  {
> > >    NSTRACE_WHEN (NSTRACE_GROUP_FOCUS, "[EmacsLayer display]");
> > >
> > > -  if (context)
> > > +  if (context && context != [NSGraphicsContext currentContext])
> > >      {
> > >        [self releaseContext];
> > >
> > >
> > > I'm not sure what the ramifications are for CACHE_MAX_SIZE 1 on slower
> > > machines, but I don't notice any performance issues on my M1.
> > >
> > > Alan, what do you think we should do? Is there anything else you think
> > > I should test for the next bit of time?
> >
> > I dug out my mac and built this and it still flickers with animated
> > gifs. It's pretty easy to make happen, so it must be some hardware
> > performance thing.
> >
> > Anyway, I've tried simplifying the double buffering code and put in
> > all the wee changes I've thought about. Who knows if this will work
> > any better...
> >
> > (It may be worth making the single/double buffering a run-time option
> > as theoretically the single buffering will perform better, although
> > always at the increased risk of tearing effects etc.)
>
> Thanks, I'll try this one out. FYI there was a typo in a comment: doible
>
> Aaron