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

Previous Next

Full log

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

From: npostavs <at> users.sourceforge.net
To: Ken Raeburn <raeburn <at> raeburn.org>
Cc: dominik.schrempf <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>,
 acairncross <at> gmail.com, clement.pit <at> gmail.com, 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Fri, 20 Jan 2017 23:54:23 -0500

merge 24091 17237
tags 24091 fixed
close 24091 26.1
quit

Ken Raeburn <raeburn <at> raeburn.org> writes:

> On Jan 17, 2017, at 21:21, npostavs <at> users.sourceforge.net wrote:
>> 
>> Do we know about any operations that require the frame be visible?  What
>> happens when they're run with an invisible frame?  Error?  Corrupted
>> display?  Hang?
>
> If drawing is done to an unmapped window, the X server can discard the
> data, but once the window is made visible, we should get an Expose
> event which would cause us to repaint the window.  The size and
> position of the window could be set by the window manager, and
> dropping the loop may mean we get to run a little more code than we
> used to before we get notified of the changes.  But these are things
> we have to deal with anyway, not just at window creation.  If we’re
> doing it right, AFAIK, we should be okay….

Okay, pushed to master [1: 6a788d2], let's see if we're doing it right.

PS Dominik I merged #17237 into this one since it appears to be the same
problem which should be fixed by this patch, please report back if it's
not.

1: 2017-01-20 23:36:26 -0500 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7
  Don't wait for frame to become visible

Previous Next

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