bug#52677: #52677 29.0.50; make-frame-visible/invisible too slow when use --with-pgtk

Johan Myréen <[email protected]>
Newsgroups gmane.emacs.bugs
Message-ID <CA+TD5hiTxwSJHdWBMbuweaH_9tki+U7vaw9LG8AELfd6PU9RYQ@mail.gmail.com>
On Thu, 20 Aug 2026 at 06:18, Dmitry Gutov <[email protected]> wrote:

> Hi Johan,
>
> Please check out the discussion and the latest patch in bug#81014, which
> is unfortunately a more recent duplicate report.
>

Oh, I have missed that bug report. I think it would be a good idea to merge
these bug reports. Looking back at the history of file src/pgtkterm.c is
see the following change in commit 5aef2623a37d9fe452b7072dbd12c7a24dd971e2
from 2022:

-  /* Map events are emitted many times, and
-   * map_event() do SET_FRAME_VISIBLE(f, 1).
-   * I expect visible = 0, so process those map events here and
-   * SET_FRAME_VISIBLE(f, 0) after that.
-   */
+  /* Handle any pending map event(s), then make the frame visible
+     manually, to avoid race conditions.  */

The original comment seems to explain what the "race condition" was, but
that piece of information was deleted by the patch. I don't know why it was
deleted—maybe it was wrong. Anyway, the comment seems to imply that
superfluous map events were seen, which messed up the logic of making the
frame invisible. These extra mapping events have, as far as I can tell,
nothing to do with the make frame visible/invisible code, so they must be
some late received asynchronous events caused by some earlier frame
mapping. I would put the blame on the code which causes these mapping
events without waiting for them, i.e. the real bug is somewhere else.

The pgtk_wait_for_map_event function looks like a horrible kludge to me,
and exists only as a safety net against events that are unexpected, and in
real life never occur, causing the timeout to always expire in its full
length. In addition, we already have an event handler for "map-event" set
in pgtk_set_event_handler, where all the event handlers are set centrally.

The timeout should really not be needed, but not only that, its value is
also totally arbitrary. Like Martin said, "a timeout is an emergency exit
to avoid waiting forever when nothing happens". Finding an appropriate
value for the timeout is impossible, it is always too long if nothing is
going to happen, or it may be too short, depending on circumstances we
don't understand.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.