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.