From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s) Date: Mon, 26 Mar 2018 22:24:03 +0300 Message-ID: <83tvt2ej3g.fsf@gnu.org> References: <83efk6g93z.fsf@gnu.org> <544b8346-bda9-45eb-9573-1d51d9f768b2@Spark> <83bmfag8gu.fsf@gnu.org> <87y3ie24z1.fsf@gmail.com> <87sh8m23tc.fsf@gmail.com> <87k1ty22p1.fsf@gmail.com> <837epyg30w.fsf@gnu.org> <83370mg0qj.fsf@gnu.org> <5AB94021.8080700@gmx.at> <83vadiek9y.fsf@gnu.org> <5AB94724.1020609@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1522092638 10172 195.159.176.226 (26 Mar 2018 19:30:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Mar 2018 19:30:38 +0000 (UTC) Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 26 21:30:34 2018 Return-path: Envelope-to: ged-emacs-devel@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 1f0XpB-0002Z1-Pw for ged-emacs-devel@m.gmane.org; Mon, 26 Mar 2018 21:30:33 +0200 Original-Received: from localhost ([::1]:58756 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f0XrF-0001A8-5W for ged-emacs-devel@m.gmane.org; Mon, 26 Mar 2018 15:32:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60612) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f0Xin-0001ob-H5 for emacs-devel@gnu.org; Mon, 26 Mar 2018 15:24:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f0Xij-0005YA-Go for emacs-devel@gnu.org; Mon, 26 Mar 2018 15:23:57 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53146) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f0Xij-0005Y6-Do; Mon, 26 Mar 2018 15:23:53 -0400 Original-Received: from [176.228.60.248] (port=3880 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1f0Xii-0004yJ-TN; Mon, 26 Mar 2018 15:23:53 -0400 In-reply-to: <5AB94724.1020609@gmx.at> (message from martin rudalics on Mon, 26 Mar 2018 21:16:52 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:224070 Archived-At: > Date: Mon, 26 Mar 2018 21:16:52 +0200 > From: martin rudalics > CC: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org > > > You mean, FRAME_VISIBLE_P is not reliable in your GTK Emacs? > > Yes. See also the thread starting here: > > https://lists.nongnu.org/archive/html/emacs-devel/2017-02/msg00133.html For the purposes of this discussion, I'll settle with a subset of my question, viz.: when FRAME_VISIBLE_P returns non-zero, is it possible that the frame is in fact not visible? If a non-zero value of FRAME_VISIBLE_P reliably tells us that the frame is visible, then we can avoid waiting for MapNotify when FRAME_VISIBLE_P returns non-zero at entry into x_make_frame_visible. (This is what the original code circa Emacs 21 did, AFAIR.)