From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org
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 [thread overview]
Message-ID: <83tvt2ej3g.fsf@gnu.org> (raw)
In-Reply-To: <5AB94724.1020609@gmx.at> (message from martin rudalics on Mon, 26 Mar 2018 21:16:52 +0200)
> Date: Mon, 26 Mar 2018 21:16:52 +0200
> From: martin rudalics <rudalics@gmx.at>
> 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.)
next prev parent reply other threads:[~2018-03-26 19:24 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-26 10:12 Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s) zhang cc
2018-03-26 15:16 ` Eli Zaretskii
2018-03-26 15:22 ` zhang cc
[not found] ` <544b8346-bda9-45eb-9573-1d51d9f768b2@Spark>
2018-03-26 15:25 ` zhang cc
2018-03-26 15:30 ` Eli Zaretskii
2018-03-26 16:09 ` Robert Pluim
2018-03-26 16:29 ` Clément Pit-Claudel
2018-03-26 16:34 ` Robert Pluim
2018-03-26 16:37 ` Noam Postavsky
2018-03-26 16:59 ` Robert Pluim
2018-03-26 17:28 ` Eli Zaretskii
2018-03-26 17:49 ` Stefan Monnier
2018-03-26 18:17 ` Eli Zaretskii
2018-03-26 18:26 ` Stefan Monnier
2018-03-26 18:33 ` Eli Zaretskii
2018-03-26 18:41 ` Stefan Monnier
2018-03-26 18:46 ` martin rudalics
2018-03-26 18:58 ` Eli Zaretskii
2018-03-26 19:16 ` martin rudalics
2018-03-26 19:24 ` Eli Zaretskii [this message]
2018-03-26 21:41 ` martin rudalics
2018-03-27 2:50 ` Eli Zaretskii
2018-03-27 7:23 ` martin rudalics
2018-03-29 9:37 ` Eli Zaretskii
2018-03-29 23:15 ` Noam Postavsky
2018-03-29 23:20 ` Noam Postavsky
2018-03-30 7:51 ` Eli Zaretskii
2018-03-26 20:09 ` Stefan Monnier
2018-03-26 21:42 ` martin rudalics
2018-03-27 2:45 ` Eli Zaretskii
2018-03-27 3:41 ` Stefan Monnier
2018-03-27 7:23 ` martin rudalics
2018-03-27 12:00 ` Stefan Monnier
2018-03-29 8:58 ` Eli Zaretskii
2018-03-26 18:46 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83tvt2ej3g.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@IRO.UMontreal.CA \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).