[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
- bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS, Kai Ma, 2023/06/08
- bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS, Kai Ma, 2023/06/08
- bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS,
Alan Third <=
- bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS, Kai Ma, 2023/06/08
- bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS, Kai Ma, 2023/06/08
- bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS, Alan Third, 2023/06/08
- bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS, Kai Ma, 2023/06/08
- bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS, Aaron Jensen, 2023/06/08
- bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS, Kai Ma, 2023/06/08
- bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS, Alan Third, 2023/06/09
- bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS, Aaron Jensen, 2023/06/09
- bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS, Alan Third, 2023/06/09
- bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS, Aaron Jensen, 2023/06/12