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

Previous Next

Full log

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

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30699 <at> debbugs.gnu.org, aaronjensen <at> gmail.com
Subject: Re: bug#30699: 26.0.91; buffer contents flicker on macOS frames when
 frames are resized
Date: Fri, 9 Mar 2018 12:09:52 +0000

On Thu, Mar 08, 2018 at 09:15:37PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 7 Mar 2018 20:26:03 +0000
> > From: Alan Third <alan <at> idiocy.org>
> > Cc: 30699 <at> debbugs.gnu.org, aaronjensen <at> gmail.com
> > 
> > updateFrameSize in nsterm.m calls SET_FRAME_GARBAGED, which appears to
> > just flag the frame for clearing.

I *finally* worked out what’s going on here.

After updateFrameSize is called we end up in x_set_window_size:

    [window setFrame: wr display: YES];

That resizes and blanks the frame, then asks it to redraw, which takes
us, eventually, to drawRect, which does:

    ns_clear_frame_area (emacsframe, x, y, width, height);
    block_input ();
    expose_frame (emacsframe, x, y, width, height);
    unblock_input ();

ns_clear_frame_area does nothing here because the frame is already
blank, and expose_frame doesn’t redraw anything because the first
thing it does is:

    /* No need to redraw if frame will be redrawn soon.  */
    if (FRAME_GARBAGED_P (f))
      {
        TRACE ((stderr, " garbaged\n"));
        return;
      }

SO, I think that the SET_GARBAGED_FRAME call in updateFrameSize is
premature, which probably means my original patch is (surprisingly)
the correct fix. Possibly with the addition of SET_GARBAGED_FRAME
after the call to setFrame in x_set_window_size, although it makes no
obvious difference here.
-- 
Alan Third

Previous Next

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