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

Previous Next

Full log

Message #47 received at 30699 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 30699 <at> debbugs.gnu.org
Subject: Re: bug#30699: 26.0.91; buffer contents flicker on macOS frames when
 frames are resized
Date: Tue, 6 Mar 2018 23:00:40 +0000

On Sun, Mar 04, 2018 at 11:55:50PM -0800, Aaron Jensen wrote:
> On Sun, Mar 4, 2018 at 1:34 PM, Alan Third <alan <at> idiocy.org> wrote:
> > The root problem is actually that we’re unable to execute redisplay
> > while the frame is being resized by a mouse. The NS event loop goes
> > into some ‘modal’ state which we can’t break out of, thus preventing
> > us from doing anything until it’s done. If that didn’t happen we
> > wouldn’t need to blank the screen at all.
> 
> Is this true on a mac as well? How are other apps like iTerm2 able to
> redraw during a resize?

The short answer is that iTerm2 is a native Cocoa app, written in the
way you should write Cocoa apps. Emacs isn’t.

The long answer is quite complicated. I’m trying to write up a decent
explanation of how the NS port works.

> It's a naive question, but is it at all possible to redraw a garbaged
> frame w/o a flicker? I know nothing about the drawing code, so I
> apologize for the question if it's dumb.

It should be, but I know very little about how Emacs goes about
drawing the frame contents, so I won’t say definitely.
-- 
Alan Third

Previous Next

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