bug#65217: 29.1; set-frame-size gets confused and drops calls

[martin rudalics <rudalics@gmx.at>]

 >> (setq my/frame
 >>
 >>         (make-frame `((left . 500)
 >>                   (top . 5)
 >>                   (width . 20)
 >>                   (height . 20)
 >>                       (parent-frame . ,(selected-frame)))))
 >>
 >> (defun my/twiddle (width height)
 >>     (set-frame-size my/frame 10 10)
 >>     (set-frame-size my/frame width height)
 >>     (message (format "%s %s" (frame-width my/frame) (frame-height
 >> my/frame))))
 >>
 >>
 >> Then (my/twiddle 20 20).
 >
 > Martin, any comments or ideas?

Many.  Basically it's a bad idea to do the above.  Setting up one size,
changing it to another one and then back to the initial one ...  But
both 'set-frame-size' calls might be hidden in larger functions and so
the above can be seen as some kind of abstraction of a larger idea.

What happens is that the (set-frame-size my/frame 10 10) has not been
yet processed by us at the time we run (set-frame-size my/frame 20 20):
Obviously so, since we run Lisp and do not process any configure events
in between.  This means that the

       if (outer_width != gwidth || outer_height != gheight)

check in gtkutil.c's xg_frame_set_char_size will tell that the window
already has the desired size and we do not send a second
gtk_window_resize request.  In fact, when replacing the above line by

       if (true) // outer_width != gwidth || outer_height != gheight)

the second request is processed and everything looks OK.  Now that check
is not utterly necessary but omitting it might, if child frames should
be hidden during resizing, provoke flickering.  Such flickering can be
already seen here with a Lucid build when running my/twiddle (otherwise
Lucid handles everything as expected).  In the case at hand it's normal,
but if the frame should not change size, it should be ideally avoided.

Unfortunately, the story does not end here.  Suppose I do

(setq my/frame
       (make-frame `((left . 500)
                     (top . 5)
                     (width . 20)
                     (height . 20))))

(defun my/twiddle (width height)
   (set-frame-size my/frame 10 10)
   (set-frame-size my/frame width height)
   (sit-for 0)
   (message (format "%s %s" (frame-width my/frame) (frame-height my/frame))))

(my/twiddle 20 20)

instead, that is my/frame is shown in a completely normal top-level
window.  In this case, the second resize request apparently gets ignored
(likely in gtk_window_move_resize but the real cause might be nested
somewhere else in the depths of GTK) and I get 10 as final width and
height which are also reported as such.  Again, Lucid has no problem
processing this scenario as expected.

As a final note, putting a (sit-for 0) in between the two
'set-frame-size' calls so that the configure event gets processed in
between, fixes both scenarios on GTK builds here.

Hence, many comments but few good ideas.  It would be interesting,
however, whether others can observe different behaviors with these
set-ups.

Thanks for your attention, martin