bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#16967: frame related race condition


From: Stefan Monnier
Subject: bug#16967: frame related race condition
Date: Fri, 14 Mar 2014 09:32:12 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

> If a frame is obscured (has visible=2) and we get a SIZE_RESTORED
> message for it, we probably should do some redisplay stuff but I'm not
> sure whether either redisplay_other_windows or SET_FRAME_GARBAGED does
> accomplish something the other doesn't.

redisplay_other_windows only tells Emacs that the next redisplay will
need to loop through all windows to see which ones need to be
redisplayed.  Without it, Emacs will only try to redisplay selected-window.

SET_FRAME_GARBAGED tells Emacs that this frame needs to be redrawn.
It calls redisplay_other_windows unconditionally.

> However, soon after I removed the conditioning on `iconified' I got my
> usually "non-redrawing a previously obscured frame" behavior and
> decided that my cure wasn't useful anyway.

Presumably, un-obscuring a frame shouldn't trigger any SIZE_RESTORED
thingy since the size is unaffected, right?

>> And we should probably also set it back to 1 when we receive expose
>> events on that frame.

Can you try to do this?

>>> BTW: The more I look into this, the more I'm convinced that implementing
>>> frame parameters on top of the old frame infrastructure was one of the
>>> worst design ideas ever.
>> I have no idea what this is referring to.
> In the case at hand it refers to the fact that when searching for the
> cause of some strange behavior of frame visibility, it's not sufficient
> to grep just for `make-frame-visible'.

Oh, that.  Yes, I'm not very happy with the use of frame-parameters to
affect "internal" frame properties.  It has never *really* bothered me,
but it seems like asking for trouble.


        Stefan





reply via email to

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