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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Raeburn <raeburn <at> raeburn.org>
Cc: dominik.schrempf <at> gmail.com, 24091 <at> debbugs.gnu.org, acairncross <at> gmail.com,
 clement.pit <at> gmail.com, npostavs <at> users.sourceforge.net
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Tue, 17 Jan 2017 05:40:02 +0200

> From: Ken Raeburn <raeburn <at> raeburn.org>
> Date: Mon, 16 Jan 2017 18:36:05 -0500
> Cc: npostavs <at> users.sourceforge.net,
>  dominik.schrempf <at> gmail.com,
>  24091 <at> debbugs.gnu.org,
>  acairncross <at> gmail.com,
>  clement.pit <at> gmail.com
> 
> > But maybe I'm wrong.  Ken, can you comment on this, please?
> 
> As I understand it, from the function’s comments and stuff I’ve read so far about the X11 and window manager protocols, the function already cannot guarantee that the window is visible when it returns, it can only request of the window manager that it make the window visible, which may or may not happen soon.  In that sense, I think Noam’s right and we could just discard the loop.
> 
> On the other hand, there are probably environments and situations (depending on the use of virtual desktops, choice of window manager, etc) where the current code does, in fact, wait for the window to appear, and won’t any more if we remove the loop.  Given that we should redraw things on expose events anyway, I’m not sure it'll matter, unless someone’s following up a call to make-frame-visible with some other action that needs to be delayed until after the window is actually visible.  I think it’s probably worth trying it to see if any differences are noticed under any of the environments people are using.

OK, let's try.

Previous Next

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