Re: 21.5 screen resize issue
- First Post
- Replies
- Stats
-
Go to
- ----- 2024 -----
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2002 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2001 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2000 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1999 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1998 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
Ron Isaacson writes:
After a resize, I see TWO calls to change_frame_size with the
correct
dimensions, while delay == 1. Each of these sets the f->new_*
variables, along with size_change_pending, then returns. Then there's
a THIRD call, again with correct dimensions, when delay == 0; that
sets size_change_pending to 0 and then we go through a full redisplay.
redisplay_frame does:
depth = enter_redisplay_critical_section ();
and gets back a depth of 3. It proceeds all the way through the
CRITICAL REDISPLAY SECTION, then when it's done, calls:
exit_redisplay_critical_section (depth);
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.
but the two f->new_* variables are still 0.
And this may make sense because change_frame_size was called on that
frame from the loop in redisplay.c at line 6719.
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.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Ron Isaacson
Monday, 3 December
Mon, 3 Dec
3:31 p.m.
New subject: 21.5 screen resize issue
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(a)morganstanley.com / (212) 276-1144
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Ron Isaacson
Monday, 3 December
Mon, 3 Dec
3:41 p.m.
New subject: 21.5 screen resize issue
Ron Isaacson wrote:
> 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...
Sure enough, that did it. Patch attached. And the screen(1) thing
turned out to be a total red herring... it so happens that all of my
console-mode usage is within screen, but the same problem happens
without it. :-)
--
Ron Isaacson
Morgan Stanley
ron.isaacson(a)morganstanley.com / (212) 276-1144
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5986
days inactive
5986
days old
2 comments
2 participants
tags (0)
participants (2)
-
Ron Isaacson -
Stephen J. Turnbull