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: Sat, 10 Mar 2018 10:15:40 +0200
> Date: Fri, 9 Mar 2018 23:24:15 +0000
> From: Alan Third <alan <at> idiocy.org>
> Cc: 30699 <at> debbugs.gnu.org, aaronjensen <at> gmail.com
> 
> 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.

But without setting the frame's garbaged flag, the following redisplay
might not produce an accurate display, and you will have that
incorrect display longer than reasonable.  The garbaged flag _must_ be
set to force a complete redraw of the frame.  If you can achieve the
same effect by other means, or if you can show that the frame will be
fully redrawn anyway, that could be a solution, but the frame _must_
be fully redrawn in this situation, after the glyph matrices of all of
its windows are reallocated to reflect the new dimensions.

So maybe a better solution would be to avoid blanking the frame when
it's resized.  Is that possible on NS?

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

Unless I'm misunderstanding, it's worse, actually.  expose_frame is
not prepared to deal with changed dimensions, it assumes that all the
dimensions are as last recorded, and that the glyph matrices
accurately describe what should be shown on the glass.  Calling
expose_frame when these assumptions are blatantly false is asking for
trouble.




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

Previous Next


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