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: Thu, 29 Mar 2018 12:37:18 +0300 Message-ID: <83fu4jdxyp.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> <83tvt2ej3g.fsf@gnu.org> <5AB96925.6080709@gmx.at> <83muyudyg1.fsf@gnu.org> <5AB9F183.3060306@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1522316200 17844 195.159.176.226 (29 Mar 2018 09:36:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Mar 2018 09:36:40 +0000 (UTC) Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: martin rudalics , Noam Postavsky Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 29 11:36:36 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 1f1Tz1-0004Wa-Ps for ged-emacs-devel@m.gmane.org; Thu, 29 Mar 2018 11:36:36 +0200 Original-Received: from localhost ([::1]:34589 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1U15-0000XE-2H for ged-emacs-devel@m.gmane.org; Thu, 29 Mar 2018 05:38:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39586) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1U04-0000T3-Su for emacs-devel@gnu.org; Thu, 29 Mar 2018 05:37:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1Tzz-0008AN-8d for emacs-devel@gnu.org; Thu, 29 Mar 2018 05:37:39 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38234) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1Tzz-0008AI-4l; Thu, 29 Mar 2018 05:37:35 -0400 Original-Received: from [176.228.60.248] (port=1907 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1f1Tzy-0000r6-5g; Thu, 29 Mar 2018 05:37:34 -0400 In-reply-to: <5AB9F183.3060306@gmx.at> (message from martin rudalics on Tue, 27 Mar 2018 09:23:47 +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:224143 Archived-At: > Date: Tue, 27 Mar 2018 09:23:47 +0200 > From: martin rudalics > CC: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org > > > It seems to me that if FRAME_VISIBLE_P can return non-zero when a > > frame is not visible, we are toast anyhow, because we have no > > reasonable way of telling whether a frame is or isn't visible. > > Waiting for 100 msec is not a guarantee for having the frame visible > > afterwards, certainly not if we don't make sure it is so at the end of > > the wait. > > > > So I'd like to see some evidence of such grave problems, before we go > > on with such a problematic assumption. > > All I meant was that if FRAME_VISIBLE_P says that the frame is visible > we should use that and we will find out soon enough if it doesn't tell > us the truth. Yes, agreed. Noam, would you like to push a change like that to master, please? > > FWIW, the original wait loop did use FRAME_VISIBLE_P as an indication > > of whether we need the wait at all: it would not enter the loop if > > FRAME_VISIBLE_P returned non-zero. > > So x_make_frame_visible should not enter the loop when FRAME_VISIBLE_P > returns non-zero but cannot rely on FRAME_VISIBLE_P to return non-zero > in order to decide whether it's safe to leave the loop. The original code did rely on FRAME_VISIBLE_P in both cases. Since we no longer process X events asynchronously, FRAME_VISIBLE_P cannot change its value while we are inside the loop, I think. But we do know whether pselect that waits for MapNotify succeeded or not, if we want/need that.