Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 26 Mar 2018 23:41:57 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org
> 
>  > 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.)
> 
> I mentioned my concerns because I obviously had the same idea.  My
> answer is simple: I think it's possible that FRAME_VISIBLE_P lies and
> we should disregard that.  If it lies, it's a good occasion to find
> out and think of a fix for Emacs 27.
> 
> And obviously I have no good ideas for Emacs 26.

We are not talking about Emacs 26.1 in any case.

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.

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.