bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames


From: Alan Third
Subject: bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized
Date: Fri, 9 Mar 2018 12:09:52 +0000
User-agent: Mutt/1.9.3 (2018-01-21)

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@idiocy.org>
> > Cc: 30699@debbugs.gnu.org, aaronjensen@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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]