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

[Eli Zaretskii]

> Date: Fri, 9 Mar 2018 12:09:52 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: 30699@debbugs.gnu.org, aaronjensen@gmail.com
> 
>     [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.

But then what would that fix solve?  The above test in expose_frame is
not a bug: if the frame is marked as garbaged (and it must be after
resizing it), then the call to expose_frame cannot possibly DTRT, so
it exits right away without doing anything.  We should enter redisplay
soon enough, which will redraw the entire frame.  If anything, then
the call to expose_frame in the control flow that reacts to frame
resizing is the one that should be removed, because it's bound to do
nothing useful.

If removing SET_FRAME_GARBAGED when the frame is resized seems to
solve some problem, then you are likely not really resizing the frame,
or not resizing it significantly enough to show why SET_FRAME_GARBAGED
is really needed.

Or maybe I'm just missing something.