GNU bug report logs -
#63187
30.0.50; Tail of longer lines painted after end of nearby lines on macOS
Previous Next
Reported by: Aaron Jensen <aaronjensen <at> gmail.com>
Date: Sun, 30 Apr 2023 10:11:01 UTC
Severity: normal
Found in version 30.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #124 received at 63187 <at> debbugs.gnu.org (full text, mbox):
> On Jun 8, 2023, at 21:42, Kai Ma <justksqsf <at> gmail.com> wrote:
>
>
>> On Jun 8, 2023, at 20:51, Alan Third <alan <at> idiocy.org> wrote:
>>
>> 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.
>
> Tested locally. I can confirm that removing performSelectorOnMainThread (with CACHE_MAX_SIZE = 2) fixes the problem for me. I now observe zero glitches or tearings!
>
Sorry, I concluded too fast. I can still see tearings, though very rarely. So this is still not a real fix. :-(
This bug report was last modified 1 year and 364 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.