21.5 screen resize issue

[Ron Isaacson]

Stephen J. Turnbull wrote:
> 
>  > Now, I confirmed that just before that call, f->size_change_pending is
>  > still 0. However, when exit_redisplay_critical_section does its
>  > unbind_to business, specpdl_depth_counter starts at 13; by the time it
>  > walks down to 3, f->size_change_pending has been reset to 1,
> 
> Hm.  I wonder if it's not size_change_pending that has been reset to
> 1, but rather f has been reset to a frame where size_change_pending is
> 1!  See the comment about size_change_pending in change_frame_size_1
> at line 3437 of frame.c, but in change_frame_size we loop over all TTY
> frames without resetting size_change_pending on frames != f at line 3460.

I think you're on to something there. I ran it again, paying more
attention to the parameters. The two passes through change_frame_size
with delay=1 are for the original frame and the new one created with
C-x 5 2, respectively. The first call with delay=0 is for the new
frame (visible), but the call after the unwind is for the original
frame (underneath).

Here's the sequence:

  1. change_frame_size (new,  delay=1)
  2. change_frame_size (orig, delay=1)
  3. change_frame_size (new,  delay=0)

The loop at the end of change_frame_size then calls
change_frame_size_1 (orig) with the proper dimensions. That function
promptly does:

  /* This size-change overrides any pending one for this frame.  */
  FRAME_NEW_HEIGHT (f) = 0;
  FRAME_NEW_WIDTH (f) = 0;

So it resets the new_* values to 0 without resetting the
size_change_pending flag.

> I gotta get some sleep, but I think that moving the reset of
> size_changed_pending to the beginning of change_frame_size_1 might help.

I agree. change_frame_size_1 is what actually effects the pending
change. I'll give it a try...

--
Ron Isaacson
Morgan Stanley
ron.isaacson at morganstanley.com / (212) 276-1144