GNU bug report logs - #24091
24.5; High CPU usage at startup while hidden

Previous Next

Full log

View this message in rfc822 format

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Aiken <acairncross <at> gmail.com>, Clément Pit--Claudel <clement.pit <at> gmail.com>, 24091 <at> debbugs.gnu.org
Subject: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Sat, 3 Sep 2016 16:03:33 -0400

On Sat, Sep 3, 2016 at 2:51 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
>> Date: Sat, 3 Sep 2016 14:40:23 -0400
>> Cc: 24091 <at> debbugs.gnu.org, Aiken <acairncross <at> gmail.com>,
>>       Clément Pit--Claudel <clement.pit <at> gmail.com>
>>
>> >> >         if ((FRAME_ICONIFIED_P (f) || FRAME_VISIBLE_P (f)) &&  ++tries > 100)
>> >> >           break;
>> >>
>> >> No, which sort of makes sense since the frame isn't actually visible.
>> >
>> > But you said the MapNotify event was received?  Doesn't that cause the
>> > frame to become marked as visible?
>>
>> Only if x_top_window_to_frame returns non-nil, which it does not.
>
> Why doesn't it, in this case, and how are things different with a
> "normal" startup, which doesn't infloop?

Hmm, it's hard to tell. In the case where Emacs is opening in the
current workspace, event->xmap.window corresponds XtWindow
(f->output_data.x->widget) and in the problematic case of opening
Emacs in another workspace, it doesn't. The contents of event are
created in the guts of Xlib I guess, which makes it somewhat
mysterious.

>
> Btw, I'm only asking these questions on the assumption that we have no
> working idea for how to solve this.  If that assumption is false, feel
> free to ignore me.

No firm ideas, but as I've been stepping around this code, I'm more
and more wondering why we have this loop at all. The comment above
x_make_frame_visible says

/* This tries to wait until the frame is really visible.
   However, if the window manager asks the user where to position
   the frame, this will return before the user finishes doing that.
   The frame will not actually be visible at that time,
   but it will become visible later when the window manager
   finishes with it.  */

So I guess the loop is the part that "tries to wait". But if that
doesn't even work some of the time, why is it really necessary at all?
The code running after this function returns can't rely on this
working, so it would have to handle the not-yet-visible case anyway...

Previous Next

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