bug#16967: frame related race condition

[martin rudalics]

>> 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.

martin