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

forcemerge 81014 52677
thanks

Johan Myréen [20/Aug  3:25pm +03] wrote:
>> 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. 

Doing so with this message.

> 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.

-- 
Sean Whitton