bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alan Third
Subject: bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS
Date: Thu, 8 Jun 2023 13:51:01 +0100

On Thu, Jun 08, 2023 at 03:33:41PM +0800, Kai Ma wrote:
> 
> 
> > On Jun 8, 2023, at 13:40, Kai Ma <justksqsf@gmail.com> wrote:
> > 
> > 
> > Hi everyone, I'm also bothered by this bug recently.  And it is
> > happening quite frequently for me.
> > 
> > Unfortunately, the proposed patch and putting
> >  [[NSGraphicsContext currentContext] flushGraphics];
> > in copyRect didn't work for me.
> > 
> > See the screencast at https://www.youtube.com/watch?v=uLYPqsUFK5A .
> 
> Upon further debugging, the following change seems to fix the problem for me.
> 
> --- a/src/nsterm.m
> +++ b/src/nsterm.m
> @@ -10433,7 +10433,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
>  {
> 
> 
> This probably implies that there is another bug somewhere else in
> the management of IOSurface caches.

I did wonder about this, but I can't see where the failure would be
happening.

I've got two things it could be worth trying to see if they make any
difference.

Change the CACHE_MAX_SIZE to something greater than 2, probably 4 is a
good number. That would rule out some sort of locking problem, as it
would reduce the chance a surface would be re-used before it's been
sent to the screen.

The downside of this is probably going to be an increase in "lag"
because it's possible to have more surfaces "in-flight".

The other option is to remove this call (nsterm.m:10636):

      /* Schedule a run of getContext so that if Emacs is idle it will
         perform the buffer copy, etc.  */
      [self performSelectorOnMainThread:@selector (getContext)
                             withObject:nil
                          waitUntilDone:NO];

I think this is harmless, but it's in there as I *assume*, with
absolutely no proof, that it will improve performance and it seems
possible (but I think unlikely) that it may affect the sequencing of
surface operations.
-- 
Alan Third





reply via email to

[Prev in Thread] Current Thread [Next in Thread]