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

Previous Next

Package: emacs;

Reported by: Aaron Jensen <aaronjensen <at> gmail.com>

Date: Sun, 4 Mar 2018 17:39:01 UTC

Severity: normal

Tags: fixed

Found in version 26.0.91

Fixed in version 27.1

Done: Alan Third <alan <at> idiocy.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

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




This bug report was last modified 7 years and 114 days ago.

Previous Next


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