GNU bug report logs - #63187
30.0.50; Tail of longer lines painted after end of nearby lines on macOS

Previous Next

Package: emacs;

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 #217 received at 63187 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: Po Lu <luangruo <at> yahoo.com>, Kai Ma <justksqsf <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 63187 <at> debbugs.gnu.org
Subject: Re: bug#63187: 30.0.50; Tail of longer lines painted after end of
 nearby lines on macOS
Date: Sun, 23 Jul 2023 12:20:21 +0100
[Message part 1 (text/plain, inline)]
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.)
-- 
Alan Third
[0001-Simplify-the-EmacsLayer-double-buffering-code-bug-63.patch (text/x-diff, attachment)]

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.