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

[Alan Third <alan@idiocy.org>]

On Fri, Mar 09, 2018 at 03:32:09PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 9 Mar 2018 12:09:52 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: 30699@debbugs.gnu.org, aaronjensen@gmail.com
> > 
> > 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.

When the window manager resizes the frame it blanks its contents out.
This results in a flicker as the full redisplay only happens after the
user sees the blanked frame. Removing, or moving, SET_FRAME_GARBAGED
allows the frame contents to be redrawn before the user sees the blank
frame.

What’s displayed is not correct but it’s shown for such a short time
that it’s not noticable, at least on my machine, and there is no
flicker.

It’s not a perfect solution, but it’s better than what we have at the
moment, IMO.

The other solution I have is to use NSDisableScreenUpdates to prevent
updates being flushed to the screen until after redisplay, but that
completely breaks resizing with the mouse.

If redisplay was able to run during interactive resizing with the
mouse then this would work, but that seems to require the NS code to
run in its own thread, which looks difficult to implement.
-- 
Alan Third