GNU bug report logs - #42834
28.0.50; macOS scroll and movement latency slows when display changes

Previous Next

Full log

View this message in rfc822 format

From: Doug Davis <ddavis <at> ddavis.io>
To: Alan Third <alan <at> idiocy.org>
Cc: 42834 <at> debbugs.gnu.org
Subject: bug#42834: 28.0.50; macOS scroll and movement latency slows when display changes
Date: Thu, 13 Aug 2020 11:42:21 -0400

Alan Third writes:

> On Wed, Aug 12, 2020 at 05:48:47PM -0400, Doug Davis wrote:
>> > Do you see the same thing going the other way? (laptop screen -> monitor)
>>
>> Ah yes, forgot to mention that- seeing it both ways.
>
> Excellent!
>
>> > Is your monitor a retina screen?
>>
>> Yeah the MacBook is retina and the external display is 4k.
>
> I think I know what's going on. If you don't use the exact same
> settings for the drawing buffer as for the screen then some very slow
> conversion processes kick in every time you flush the buffer to the
> screen.
>
> Odds are that the monitor and laptop screen have something slightly
> different, probably a colorspace or something, so when switching from
> one to the other the drawing buffer retains the settings for the old
> screen.
>
> Can you try the following change in nsterm.m?
>
> @@ -8431,18 +8431,10 @@ - (void)windowDidChangeBackingProperties:(NSNotification *)notification
>    if (! [self wantsUpdateLayer])
>      return;
>
> -  CGFloat old = [[[notification userInfo]
> -                    objectForKey:@"NSBackingPropertyOldScaleFactorKey"]
> -                  doubleValue];
> -  CGFloat new = [[self window] backingScaleFactor];
> -
> -  if (old != new)
> -    {
> -      NSRect frame = [self frame];
> -      [self createDrawingBuffer];
> -      ns_clear_frame (emacsframe);
> -      expose_frame (emacsframe, 0, 0, NSWidth (frame), NSHeight (frame));
> -    }
> +  NSRect frame = [self frame];
> +  [self createDrawingBuffer];
> +  ns_clear_frame (emacsframe);
> +  expose_frame (emacsframe, 0, 0, NSWidth (frame), NSHeight (frame));
>  }
>  #endif /* NS_DRAW_TO_BUFFER */

That patch does indeed appear to be the solution-- tested the exact same
situation and now without the sluggishness issue.

Thanks!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.