GNU bug report logs - #16967
frame related race condition

Previous Next

Package: emacs;

Reported by: Juanma Barranquero <lekktu <at> gmail.com>

Date: Sat, 8 Mar 2014 16:21:02 UTC

Severity: normal

Found in version 24.3.50

Done: Juanma Barranquero <lekktu <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


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

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 16967 <at> debbugs.gnu.org
Subject: Re: bug#16967: frame related race condition
Date: Fri, 14 Mar 2014 12:31:57 +0100
> Hmm... I didn't realize this "visible=2" is also used in the Windows GUI.
> So maybe the "visible=2" case under Windows is indeed mishandled by the
> "redisplay bit" code.  Or by some other part of the code.

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

> I'm not sure what SIZE_RESTORED is for, but indeed when we receive
> a size-change notification, the "visible=2" optimization might not be
> valid any more so we should set it back to 1.
>
> And we should probably also set it back to 1 when we receive expose
> events on that frame.
>
> But I'm generally clueless about GUI code, and even more clueless about
> w32, so please don't take my word for it.

As explained above, I haven't been able to stop the indecent behavior of
obscured frames I observed with an even more radical approach, so I'm
clueless as well.

>> 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'.  You also have to spot things
like (set-frame-parameter frame 'visibility t) and maybe all occurrences
of `modify-frame-parameters' and `modify-all-frames-parameters'.
Obviously searching for 'visibility only is more efficient but this will
fail miserably with more mundane words like `right' or `left'.  So the
introduction of frame parametes often multiplies the effort necessary to
find the cause of frame related bugs.

martin




This bug report was last modified 5 years and 292 days ago.

Previous Next


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