GNU bug report logs - #30699
26.0.91; buffer contents flicker on macOS frames when frames are resized

Previous Next

Full log

Message #11 received at 30699 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 30699 <at> debbugs.gnu.org
Subject: Re: bug#30699: 26.0.91; buffer contents flicker on macOS frames when
 frames are resized
Date: Sun, 4 Mar 2018 21:34:04 +0000

[Message part 1 (text/plain, inline)]

On Sun, Mar 04, 2018 at 08:27:36PM +0000, Alan Third wrote:
> On Sun, Mar 04, 2018 at 09:38:27AM -0800, Aaron Jensen wrote:
> > It appears that (on macOS, at least) when a frame is resized, there is
> > an unsightly flicker. It does not matter if the frame is undecorated or
> > not.
> 
> Simpler repro:
> 
> (dotimes (n 10)
>   (set-frame-parameter nil 'width (+ 80 n))
>   (sit-for 0.1))
> 

It’s the call to SET_FRAME_GARBAGED in EmacsView::updateFrameSize. I
don’t know if it’s needed in this circumstance, but without it it
stops the frame being blanked when resizing with the mouse, which is
unpleasant.

The attached patch appears to fix it without breaking mouse resizing,
but it looks like this comment in windowDidResize also counts for macOS:

   /* In GNUstep, at least currently, it's possible to get a didResize
      without getting a willResize.. therefore we need to act as if we got
      the willResize now */

I honestly don’t see that it makes any difference though.

The root problem is actually that we’re unable to execute redisplay
while the frame is being resized by a mouse. The NS event loop goes
into some ‘modal’ state which we can’t break out of, thus preventing
us from doing anything until it’s done. If that didn’t happen we
wouldn’t need to blank the screen at all.
-- 
Alan Third

[0001-Fix-flicker-when-resizing-frame-on-macOS-bug-30699.patch (text/plain, attachment)]

Previous Next

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