[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#16967: frame related race condition

From: martin rudalics
Subject: bug#16967: frame related race condition
Date: Tue, 11 Mar 2014 09:07:36 +0100

>> Lately I frequently noticed that an Emacs frame that was for some time
>> hidden by other applications and subsequently became exposed by deleting
>> their windows was not redrawn and I would like to know whether this was
>> the reason.  ISTR that others noted the same or a similar misbehavior.
> My "redisplay bit" changes of a few months back introduced such bugs.
> I haven't seen such problems for a while now, so I think I've caught all
> the problems, but maybe I still missed some.
> Part of the change is that previously iconified/invisible frames where
> redisplayed right away (i.e. their glyph matrices were kept up-to-date),
> whereas now they're not.  Which means that when they're uniconified or
> made visible, we have to first set windows_or_buffers_changed to
> REDISPLAY_SOME, to make sure that the subsequent redisplay doesn't
> forget to look at them.

In all cases I observed this, the Emacs frame was neither invisible nor
iconified before, hence there was no uniconifying or making it visible
involved.  And since I don't recall observing this problem on GNU/Linux,
I'm quite convinced that it's merely Emacs mishandling frames obscured
for some time on Windows.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]