From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Noam Postavsky Newsgroups: gmane.emacs.bugs Subject: bug#24091: 24.5; High CPU usage at startup while hidden Date: Sat, 3 Sep 2016 16:03:33 -0400 Message-ID: References: <24533f31-9fc2-b38e-aaeb-561616cdf77f@gmail.com> <87shut9pyk.fsf@users.sourceforge.net> <83lh0lq9n5.fsf@gnu.org> <83oa5fp1zb.fsf@gnu.org> <877fbkw7b1.fsf@users.sourceforge.net> <83inv1fnf9.fsf@gnu.org> <83zinodghv.fsf@gnu.org> <83y438de6m.fsf@gnu.org> <83wpisddgb.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1472933066 26447 195.159.176.226 (3 Sep 2016 20:04:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Sep 2016 20:04:26 +0000 (UTC) Cc: Aiken , =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel , 24091@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 03 22:04:21 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bgHAp-00063J-0O for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Sep 2016 22:04:19 +0200 Original-Received: from localhost ([::1]:47581 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgHAm-0008Jd-SH for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Sep 2016 16:04:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47290) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgHAd-0008IA-1z for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2016 16:04:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bgHAY-0005ix-Sd for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2016 16:04:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51270) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgHAY-0005it-PN for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2016 16:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bgHAY-0002XO-Aw for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2016 16:04:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Sep 2016 20:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 24091-submit@debbugs.gnu.org id=B24091.14729330229726 (code B ref 24091); Sat, 03 Sep 2016 20:04:02 +0000 Original-Received: (at 24091) by debbugs.gnu.org; 3 Sep 2016 20:03:42 +0000 Original-Received: from localhost ([127.0.0.1]:48982 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bgHAD-0002Wo-So for submit@debbugs.gnu.org; Sat, 03 Sep 2016 16:03:42 -0400 Original-Received: from mail-oi0-f44.google.com ([209.85.218.44]:33658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bgHAB-0002Wc-WF for 24091@debbugs.gnu.org; Sat, 03 Sep 2016 16:03:40 -0400 Original-Received: by mail-oi0-f44.google.com with SMTP id c15so204186757oig.0 for <24091@debbugs.gnu.org>; Sat, 03 Sep 2016 13:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=fz2umYAatnwZI8QapZhgwozuJxRo9Kl9L2ZfHT4Or/g=; b=j6OZ8+kJSARcvqJKcc2BB3sYUSoldGfrIqliboTc4N14DcEbhls0nmn6yZgnfRnQfz /fvY8VI/fscVd7KSsQ1CCsEag7zGTWQPC/CmGleXGYFlV1uAwPZoX21Sg+TmHjcfHdap JWvTSlq9BLPbauxtXBfjxX/u30214LdxJCk7IYfB/u90zqorZECkqI9DHFU7OxJw1j6J dO6/AG5P0Rjfryi39L0tt6kCTk8Bqyv4WShISppf3yZp9Ro/0cGa2NNZ5SIDiwtGhBZB eBincBaDlqg29YwnAUdBZHLi6d53yNY93DjWcMJzbhJ/dPMe143gaJqsKjlJYeSRJZTz tknw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=fz2umYAatnwZI8QapZhgwozuJxRo9Kl9L2ZfHT4Or/g=; b=ZZW3YYW4rvi0guwAgmSwYYAdAw/V62y7B1nmZSEqNj3CgDurLGjlmXpxeOpodZ+o5E x0DS49mLJHve1hSJMoJLIkOvVJvNuYi9MvsBrJt6f9qI12QO/2BOG/NL9PrhRZS/u2dP 97MSv4sVLOnUIYn5aMEZJ6tLuqiiqA5uoRUBPUmrzNY7nVigiB3wkZ0M2OlD9ceMDddl I6tH1qyNxi7KILZ0FInE/azJvB8QLaVvuypu5SSvScJT20zt6wJf4SbXIlaSdBe3grnm b1JB/wVcd5LNDyGnKQ71tHb7uEEFeSIL6ofPKfPqUGdONbIEK4sASpmXBTmMbUD1ZF0P glYA== X-Gm-Message-State: AE9vXwMArK2FrsRvi8b4XsD0ff+iuhlMFDuLDy24LVaJkAsnWhmpaC+6sRztmHcUppQBTghgJAWTR05PtlsKMA== X-Received: by 10.202.195.1 with SMTP id t1mr25026926oif.144.1472933014417; Sat, 03 Sep 2016 13:03:34 -0700 (PDT) Original-Received: by 10.157.7.195 with HTTP; Sat, 3 Sep 2016 13:03:33 -0700 (PDT) In-Reply-To: <83wpisddgb.fsf@gnu.org> X-Google-Sender-Auth: 3JafDcQqxeKC6f2dS57zw8GiFLg X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:122911 Archived-At: On Sat, Sep 3, 2016 at 2:51 PM, Eli Zaretskii wrote: >> From: Noam Postavsky >> Date: Sat, 3 Sep 2016 14:40:23 -0400 >> Cc: 24091@debbugs.gnu.org, Aiken , >> Cl=C3=A9ment Pit--Claudel >> >> >> > if ((FRAME_ICONIFIED_P (f) || FRAME_VISIBLE_P (f)) && ++tr= ies > 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...