bug#16736: Compiling a Lisp file causes display to flash off and on

bug#16736: Compiling a Lisp file causes display to flash off and on

[Glenn Morris]

Package: emacs
Version: 24.3.50

Current trunk on x86_64 GNU/Linux, Lucid toolkit.

Visit some non-trivial file that compiles with no warnings:

  emacs -Q some-file.el
  M-x byte-compile-file RET RET


During the resulting compilation, at some point it looks like the Emacs
display goes completely blank. It happens a bit fast, so it is hard to
say exactly. It does not look to me as if it is switching to another
buffer (Compile-Log) and back again. It's like the display flashes off
and on. The tool-bar, mode line also disappear.

This effect does not happen with 24.3.

bug#16736: Compiling a Lisp file causes display to flash off and on

[Glenn Morris]

I'm noticing display flashes in other situations too. Eg with simply
emacs -Q, then repeating C-x 2, C-x 1 in sequence, I notice the toolbar
flashing quickly off and on. Not every time, but often. It's rather
distracting. I do not observe this with 24.3.

bug#16736: Compiling a Lisp file causes display to flash off and on

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 14 Feb 2014 01:42:29 -0500
> 
> 
> I'm noticing display flashes in other situations too. Eg with simply
> emacs -Q, then repeating C-x 2, C-x 1 in sequence, I notice the toolbar
> flashing quickly off and on. Not every time, but often. It's rather
> distracting. I do not observe this with 24.3.

I tried to reproduce your original report, but couldn't, perhaps
because I couldn't find a large enough Lisp file that compiles without
warnings.  Can you tell which file did you use?

As for toolbar flickering with repeated "C-x 2" and "C-x 1", I don't
see it here.  Is this with a configuration where Emacs draws the
toolbar, or is the toolbar drawn by the toolkit?

bug#16736: Compiling a Lisp file causes display to flash off and on

[Glenn Morris]

Eli Zaretskii wrote:

> I tried to reproduce your original report, but couldn't, perhaps
> because I couldn't find a large enough Lisp file that compiles without
> warnings.  Can you tell which file did you use?

I think I randomly used progmodes/scheme.el, but added

(require 'gnus)
(require 'org)

at the start, and deleted gnus/*.elc and org/*.elc to slow things down.

Basically make the slowest compilation you can, so long as there are no
warnings. It seems to be right at the end of the compilation that the
flash occurs.

> As for toolbar flickering with repeated "C-x 2" and "C-x 1", I don't
> see it here.  Is this with a configuration where Emacs draws the
> toolbar, or is the toolbar drawn by the toolkit?

--with-x-toolkit=athena --without-toolkit-scroll-bars

bug#16736: Compiling a Lisp file causes display to flash off and on

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 16736@debbugs.gnu.org
> Date: Fri, 14 Feb 2014 02:48:31 -0500
> 
> Eli Zaretskii wrote:
> 
> > I tried to reproduce your original report, but couldn't, perhaps
> > because I couldn't find a large enough Lisp file that compiles without
> > warnings.  Can you tell which file did you use?
> 
> I think I randomly used progmodes/scheme.el, but added
> 
> (require 'gnus)
> (require 'org)
> 
> at the start, and deleted gnus/*.elc and org/*.elc to slow things down.
> 
> Basically make the slowest compilation you can, so long as there are no
> warnings. It seems to be right at the end of the compilation that the
> flash occurs.

I don't see any flash here.

What you describe, viz.:

> During the resulting compilation, at some point it looks like the Emacs
> display goes completely blank. It happens a bit fast, so it is hard to
> say exactly. It does not look to me as if it is switching to another
> buffer (Compile-Log) and back again. It's like the display flashes off
> and on. The tool-bar, mode line also disappear.

sounds like the frame is cleared and completely redrawn, which I won't
expect during byte-compile, which only redisplays the echo area.  If I
put a breakpoint in clear_frame, it is never hit during your recipe.

> > As for toolbar flickering with repeated "C-x 2" and "C-x 1", I don't
> > see it here.  Is this with a configuration where Emacs draws the
> > toolbar, or is the toolbar drawn by the toolkit?
> 
> --with-x-toolkit=athena --without-toolkit-scroll-bars

These symptoms seem to indicate that the tool bar is redrawn, whereas
it shouldn't be, because its content is unchanged by "C-x 2".  I don't
see any flickering here, so please step with GDB through the affected
code, as described below, and tell what you see.

I also tried this recipe:

  (while t
    (split-window-below)
    (sit-for 0.05)
    (delete-other-windows)
    (sit-for 0.05))

Typing "C-x C-e" at the right paren of this in *scratch*, I see no
flickering in the tool bar.  Do you?

To find out why does the tool-bar flicker, please step into the
portion of redisplay that redraws the tool bar.  Its entry point is in
update_frame, like this:

  #if defined (HAVE_WINDOW_SYSTEM) && ! defined (USE_GTK) && ! defined (HAVE_NS)
	/* Update the tool-bar window, if present.  */
	if (WINDOWP (f->tool_bar_window))
	  {
	    struct window *w = XWINDOW (f->tool_bar_window);

	    /* Update tool-bar window.  */
	    if (w->must_be_updated_p)
	      {
		Lisp_Object tem;

		update_window (w, 1);
		w->must_be_updated_p = false;

		/* Swap tool-bar strings.  We swap because we want to
		   reuse strings.  */
		tem = f->current_tool_bar_string;
		fset_current_tool_bar_string (f, f->desired_tool_bar_string);
		fset_desired_tool_bar_string (f, tem);
	      }
	  }
  #endif

Please step into the update_window call above.  There you should see
that we perform this loop:

      /* Update the rest of the lines.  */
      for (; row < end && (force_p || !input_pending); ++row)
	/* scrolling_window resets the enabled_p flag of the rows it
	   reuses from current_matrix.  */
	if (row->enabled_p)
	  {

Then step into update_window_line call in that loop.  The glyph rows
of the tool-bar window don't have marginal areas, so when the loop
calls update_window_line, only update_text_area is called from
update_window_line.  There's call in update_text_area that compares
the glyph row of the current glyph matrix (which reflects what is on
the screen) and the desired glyph matrix (which says what should be on
the screen).  The comparison code starts with this:

      stop = min (current_row->used[TEXT_AREA], desired_stop_pos);
      i = 0;
      x = desired_row->x;

      /* Loop over glyphs that current and desired row may have
	 in common.  */
      while (i < stop)
	{

In my case, current_row and desired_row are exactly equal, so the tool
bar is never redrawn.  Please see if things are different in your
case, and why.

You can display the contents of the glyph row with the pgrowx command
(defined on src/.gdbinit), like this:

  (gdb) pgrowx current_row
  TEXT: 13 glyphs
    0    0: IMAGE[10] str=0x3a9f394[0] w=35 a+d=14+21 face=3 MB [ slice=0,0,24,24
    1   35: IMAGE[11] str=0x3a9f394[1] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
    2   69: IMAGE[12] str=0x3a9f394[2] w=29 a+d=14+21 face=3 MB slice=0,0,19,24
    3   98: IMAGE[13] str=0x3a9f394[3] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
    4  132: IMAGE[14] str=0x3a9f394[4] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
    5  166: IMAGE[15] str=0x3a9f394[5] w=12 a+d=14+21 face=3 MB slice=0,0,2,24
    6  178: IMAGE[16] str=0x3a9f394[6] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
    7  212: IMAGE[15] str=0x3a9f394[7] w=12 a+d=14+21 face=3 MB slice=0,0,2,24
    8  224: IMAGE[17] str=0x3a9f394[8] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
    9  258: IMAGE[18] str=0x3a9f394[9] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
   10  292: IMAGE[19] str=0x3a9f394[10] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
   11  326: IMAGE[15] str=0x3a9f394[11] w=12 a+d=14+21 face=3 MB slice=0,0,2,24
   12  338: IMAGE[20] str=0x3a9f394[12] w=34 a+d=14+21 face=3 MB ] slice=0,0,24,24

Thanks.

bug#16736: Compiling a Lisp file causes display to flash off and on

[Eli Zaretskii]

> Date: Sat, 15 Feb 2014 10:24:44 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 16736@debbugs.gnu.org
> 
> Then step into update_window_line call in that loop.  The glyph rows
> of the tool-bar window don't have marginal areas, so when the loop
> calls update_window_line, only update_text_area is called from
> update_window_line.  There's call in update_text_area that compares
                               ^^^^
This should have been "code", sorry.

bug#16736: Compiling a Lisp file causes display to flash off and on

[Glenn Morris]

Eli Zaretskii wrote:

> sounds like the frame is cleared and completely redrawn, which I won't
> expect during byte-compile, which only redisplays the echo area.  If I
> put a breakpoint in clear_frame, it is never hit during your recipe.

I put a break on x_clear_frame, and with emacs -Q, byte-compile-file on
scheme.el triggers it.

>   (while t
>     (split-window-below)
>     (sit-for 0.05)
>     (delete-other-windows)
>     (sit-for 0.05))
>
> Typing "C-x C-e" at the right paren of this in *scratch*, I see no
> flickering in the tool bar.  Do you?

Oh yes. It looks awful!

In an attempt to follow your instructions, I put a break on dispnew.c:3045.

So far I don't think I am getting any useful information out of this,
because it seems to trigger a lot, and I'm not sure I'm catching it at
the right time. I'll try again later, but frankly I don't know what I'm
doing, even with your detailed instructions.

Here's current_row and desired_row in update_text_area one time.

TEXT: 13 glyphs
  0    0: IMAGE[10] str=0x13fb5c8[0] w=35 a+d=14+21 face=3 MB [ slice=0,0,24,24
  1   35: IMAGE[11] str=0x13fb5c8[1] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
  2   69: IMAGE[12] str=0x13fb5c8[2] w=29 a+d=14+21 face=3 MB slice=0,0,19,24
  3   98: IMAGE[13] str=0x13fb5c8[3] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
  4  132: IMAGE[14] str=0x13fb5c8[4] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
  5  166: IMAGE[15] str=0x13fb5c8[5] w=12 a+d=14+21 face=3 MB slice=0,0,2,24
  6  178: IMAGE[16] str=0x13fb5c8[6] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
  7  212: IMAGE[15] str=0x13fb5c8[7] w=12 a+d=14+21 face=3 MB slice=0,0,2,24
  8  224: IMAGE[17] str=0x13fb5c8[8] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
  9  258: IMAGE[18] str=0x13fb5c8[9] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
 10  292: IMAGE[19] str=0x13fb5c8[10] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
 11  326: IMAGE[15] str=0x13fb5c8[11] w=12 a+d=14+21 face=3 MB slice=0,0,2,24
 12  338: IMAGE[20] str=0x13fb5c8[12] w=34 a+d=14+21 face=3 MB ] slice=0,0,24,24
TEXT: 13 glyphs
  0    0: IMAGE[10] str=0x13fbe90[0] w=35 a+d=14+21 face=3 MB [ slice=0,0,24,24
  1   35: IMAGE[11] str=0x13fbe90[1] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
  2   69: IMAGE[12] str=0x13fbe90[2] w=29 a+d=14+21 face=3 MB slice=0,0,19,24
  3   98: IMAGE[13] str=0x13fbe90[3] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
  4  132: IMAGE[14] str=0x13fbe90[4] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
  5  166: IMAGE[15] str=0x13fbe90[5] w=12 a+d=14+21 face=3 MB slice=0,0,2,24
  6  178: IMAGE[16] str=0x13fbe90[6] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
  7  212: IMAGE[15] str=0x13fbe90[7] w=12 a+d=14+21 face=3 MB slice=0,0,2,24
  8  224: IMAGE[17] str=0x13fbe90[8] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
  9  258: IMAGE[18] str=0x13fbe90[9] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
 10  292: IMAGE[19] str=0x13fbe90[10] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
 11  326: IMAGE[15] str=0x13fbe90[11] w=12 a+d=14+21 face=3 MB slice=0,0,2,24
 12  338: IMAGE[20] str=0x13fbe90[12] w=34 a+d=14+21 face=3 MB ] slice=0,0,24,24

bug#16736: Compiling a Lisp file causes display to flash off and on

[Glenn Morris]

Glenn Morris wrote:

>>   (while t
>>     (split-window-below)
>>     (sit-for 0.05)
>>     (delete-other-windows)
>>     (sit-for 0.05))
>>
>> Typing "C-x C-e" at the right paren of this in *scratch*, I see no
>> flickering in the tool bar.  Do you?
>
> Oh yes. It looks awful!

Bisected to:
    
    revno: 115971
    committer: martin rudalics <rudalics@gmx.at>
    branch nick: trunk
    timestamp: Sat 2014-01-11 10:31:09 +0100
    message:
      Fix handling of internal borders (Bug#16348).

bug#16736: Compiling a Lisp file causes display to flash off and on

[martin rudalics]

 > Bisected to:
 >
 >     revno: 115971
 >     committer: martin rudalics <rudalics@gmx.at>
 >     branch nick: trunk
 >     timestamp: Sat 2014-01-11 10:31:09 +0100
 >     message:
 >       Fix handling of internal borders (Bug#16348).

Does anything change when you set the frame's internal border width to
zero?  Does anything change when you disable the calls to
x_clear_under_internal_border?  If so, can you spot one of these calls
as the offending one?  I'm yet too silly to understand what's going on
here.

Thanks, martin

bug#16736: Compiling a Lisp file causes display to flash off and on

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 16736@debbugs.gnu.org
> Date: Sat, 15 Feb 2014 16:28:13 -0500
> 
> 
> Eli Zaretskii wrote:
> 
> > sounds like the frame is cleared and completely redrawn, which I won't
> > expect during byte-compile, which only redisplays the echo area.  If I
> > put a breakpoint in clear_frame, it is never hit during your recipe.
> 
> I put a break on x_clear_frame, and with emacs -Q, byte-compile-file on
> scheme.el triggers it.

Can you show a backtrace from that breakpoint?

> In an attempt to follow your instructions, I put a break on dispnew.c:3045.
> 
> So far I don't think I am getting any useful information out of this,
> because it seems to trigger a lot, and I'm not sure I'm catching it at
> the right time.

I'm interested in seeing what happens the first time this breakpoint
breaks after you type "C-x 2" in *scratch*.  (On my system, this is
the only time it breaks after "C-x 2"; do you see something
different?)

> Here's current_row and desired_row in update_text_area one time.
> 
> TEXT: 13 glyphs
>   0    0: IMAGE[10] str=0x13fb5c8[0] w=35 a+d=14+21 face=3 MB [ slice=0,0,24,24
>   1   35: IMAGE[11] str=0x13fb5c8[1] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
>   2   69: IMAGE[12] str=0x13fb5c8[2] w=29 a+d=14+21 face=3 MB slice=0,0,19,24
>   3   98: IMAGE[13] str=0x13fb5c8[3] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
>   4  132: IMAGE[14] str=0x13fb5c8[4] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
>   5  166: IMAGE[15] str=0x13fb5c8[5] w=12 a+d=14+21 face=3 MB slice=0,0,2,24
>   6  178: IMAGE[16] str=0x13fb5c8[6] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
>   7  212: IMAGE[15] str=0x13fb5c8[7] w=12 a+d=14+21 face=3 MB slice=0,0,2,24
>   8  224: IMAGE[17] str=0x13fb5c8[8] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
>   9  258: IMAGE[18] str=0x13fb5c8[9] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
>  10  292: IMAGE[19] str=0x13fb5c8[10] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
>  11  326: IMAGE[15] str=0x13fb5c8[11] w=12 a+d=14+21 face=3 MB slice=0,0,2,24
>  12  338: IMAGE[20] str=0x13fb5c8[12] w=34 a+d=14+21 face=3 MB ] slice=0,0,24,24
> TEXT: 13 glyphs
>   0    0: IMAGE[10] str=0x13fbe90[0] w=35 a+d=14+21 face=3 MB [ slice=0,0,24,24
>   1   35: IMAGE[11] str=0x13fbe90[1] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
>   2   69: IMAGE[12] str=0x13fbe90[2] w=29 a+d=14+21 face=3 MB slice=0,0,19,24
>   3   98: IMAGE[13] str=0x13fbe90[3] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
>   4  132: IMAGE[14] str=0x13fbe90[4] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
>   5  166: IMAGE[15] str=0x13fbe90[5] w=12 a+d=14+21 face=3 MB slice=0,0,2,24
>   6  178: IMAGE[16] str=0x13fbe90[6] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
>   7  212: IMAGE[15] str=0x13fbe90[7] w=12 a+d=14+21 face=3 MB slice=0,0,2,24
>   8  224: IMAGE[17] str=0x13fbe90[8] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
>   9  258: IMAGE[18] str=0x13fbe90[9] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
>  10  292: IMAGE[19] str=0x13fbe90[10] w=34 a+d=14+21 face=3 MB slice=0,0,24,24
>  11  326: IMAGE[15] str=0x13fbe90[11] w=12 a+d=14+21 face=3 MB slice=0,0,2,24
>  12  338: IMAGE[20] str=0x13fbe90[12] w=34 a+d=14+21 face=3 MB ] slice=0,0,24,24

These look identical to me.  Are you saying that tracing into
update_window_line and then update_text_area for these two, you see
that the loop which starts at line 3598 ends with i's value smaller
than desired_row->used[TEXT_AREA], and you see these 3 lines (3696 to
3698) being executed:

	      output_cursor_to (w, vpos, start_hpos, desired_row->y, start_x);
	      rif->write_glyphs (w, updated_row, start,
				 TEXT_AREA, i - start_hpos);
	      changed_p = 1;

Again, please trace all this upon the first time the breakpoint on
line 3045 breaks after "C-x 2".

> I'll try again later, but frankly I don't know what I'm doing, even
> with your detailed instructions.

Thanks.  Feel free to ask questions about things you'd like to
understand.  In a nutshell, this is part of the code that updates the
window after Emacs has determined that some window(s) need to be
updated, in this case, due to "C-x 2" that created a new window and
made the old one smaller.  The code I pointed to updates the tool-bar
window when anything on the tool bar changes, or refrains from
updating it if the tool bar did not change at all (which should happen
in this case).

bug#16736: Compiling a Lisp file causes display to flash off and on

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 16736@debbugs.gnu.org, martin rudalics <rudalics@gmx.at>
> Date: Sat, 15 Feb 2014 17:07:38 -0500
> 
> Glenn Morris wrote:
> 
> >>   (while t
> >>     (split-window-below)
> >>     (sit-for 0.05)
> >>     (delete-other-windows)
> >>     (sit-for 0.05))
> >>
> >> Typing "C-x C-e" at the right paren of this in *scratch*, I see no
> >> flickering in the tool bar.  Do you?
> >
> > Oh yes. It looks awful!
> 
> Bisected to:
>     
>     revno: 115971
>     committer: martin rudalics <rudalics@gmx.at>
>     branch nick: trunk
>     timestamp: Sat 2014-01-11 10:31:09 +0100
>     message:
>       Fix handling of internal borders (Bug#16348).

Thanks, but I think we still need more info to find what caused this,
as most of that commit is for non-toolkit builds.

Can you put a breakpoint in change_frame_size_1, on line 5564:

  SET_FRAME_COLS (f, new_cols); <<<<<<<<<<<<<<<<
  FRAME_LINES (f) = new_lines;
  FRAME_TEXT_WIDTH (f) = new_text_width;

and see if that breakpoint breaks when you type "C-x 2" in *scratch*?
If it does break, can you show the values of these:

  new_text_width
  FRAME_TEXT_WIDTH (f)
  new_root_width
  old_root_width
  FRAME_TEXT_TO_PIXEL_WIDTH (f, new_text_width)
  FRAME_INTERNAL_BORDER_WIDTH (f)

bug#16736: Compiling a Lisp file causes display to flash off and on

[Eli Zaretskii]

> Date: Sun, 16 Feb 2014 11:31:29 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, 16736@debbugs.gnu.org
> 
>  > Bisected to:
>  >
>  >     revno: 115971
>  >     committer: martin rudalics <rudalics@gmx.at>
>  >     branch nick: trunk
>  >     timestamp: Sat 2014-01-11 10:31:09 +0100
>  >     message:
>  >       Fix handling of internal borders (Bug#16348).
> 
> Does anything change when you set the frame's internal border width to
> zero?  Does anything change when you disable the calls to
> x_clear_under_internal_border?  If so, can you spot one of these calls
> as the offending one?  I'm yet too silly to understand what's going on
> here.

Btw, the bug was about non-toolkit builds, but at least one of the
hunks affects toolkit builds as well.  Not sure if that was intended.

bug#16736: Compiling a Lisp file causes display to flash off and on

[martin rudalics]

 > Btw, the bug was about non-toolkit builds, but at least one of the
 > hunks affects toolkit builds as well.  Not sure if that was intended.

It was intended.  A related bug showed up also on the Windows build.
I then checked the border behavior on all builds I made.

Basically, the changes should only clear areas where display artifacts
show up.  It does that somewhat brute forcish (similar to the Gtk build)
but I can't yet imagine that these could screw up redisplay that much.

martin

bug#16736: Compiling a Lisp file causes display to flash off and on

[Glenn Morris]

Eli Zaretskii wrote:

>> I put a break on x_clear_frame, and with emacs -Q, byte-compile-file on
>> scheme.el triggers it.
>
> Can you show a backtrace from that breakpoint?

Easy enough.

#0  x_clear_frame (f=0x11cd8b8) at xterm.c:2909
#1  0x00000000004ece00 in clear_frame (f=0x11cd8b8) at terminal.c:140
#2  0x0000000000417f8f in redraw_frame (f=0x11cd8b8) at dispnew.c:2955
#3  0x0000000000448e4d in clear_garbaged_frames () at xdisp.c:10935
#4  0x0000000000448fb9 in echo_area_display (update_frame_p=1) at xdisp.c:10979
#5  0x000000000044703a in message3_nolog (m=14191025) at xdisp.c:9987
#6  0x0000000000446de9 in message3 (m=14191025) at xdisp.c:9929
#7  0x00000000005b560f in Fmessage (nargs=3, args=0x7fffffff8338)
    at editfns.c:3452
#8  0x00000000005c0e83 in Ffuncall (nargs=4, args=0x7fffffff8330)
    at eval.c:2796
#9  0x0000000000600e44 in exec_byte_code (bytestr=13161473, vector=19239277, 
    maxdepth=72, args_template=5140, nargs=5, args=0x7fffffff88d8)
    at bytecode.c:919
#10 0x00000000005c16b2 in funcall_lambda (fun=18472445, nargs=5, 
    arg_vector=0x7fffffff88b0) at eval.c:2983
#11 0x00000000005c11a7 in Ffuncall (nargs=6, args=0x7fffffff88a8)
    at eval.c:2864
#12 0x0000000000600e44 in exec_byte_code (bytestr=14003153, vector=18902205, 
    maxdepth=32, args_template=2056, nargs=2, args=0x7fffffff8e68)
    at bytecode.c:919
#13 0x00000000005c16b2 in funcall_lambda (fun=18951917, nargs=2, 
    arg_vector=0x7fffffff8e58) at eval.c:2983
#14 0x00000000005c11a7 in Ffuncall (nargs=3, args=0x7fffffff8e50)
    at eval.c:2864
#15 0x0000000000600e44 in exec_byte_code (bytestr=14003009, vector=18997205, 
    maxdepth=64, args_template=6168, nargs=6, args=0x7fffffff9420)
    at bytecode.c:919
#16 0x00000000005c16b2 in funcall_lambda (fun=18997301, nargs=6, 
    arg_vector=0x7fffffff93f0) at eval.c:2983
#17 0x00000000005c11a7 in Ffuncall (nargs=7, args=0x7fffffff93e8)
    at eval.c:2864
#18 0x0000000000600e44 in exec_byte_code (bytestr=14002977, vector=18073693, 
    maxdepth=68, args_template=5140, nargs=5, args=0x7fffffff99e8)
    at bytecode.c:919
#19 0x00000000005c16b2 in funcall_lambda (fun=18997349, nargs=5, 
    arg_vector=0x7fffffff99c0) at eval.c:2983
#20 0x00000000005c11a7 in Ffuncall (nargs=6, args=0x7fffffff99b8)
    at eval.c:2864
#21 0x0000000000600e44 in exec_byte_code (bytestr=14002785, vector=18997397, 
    maxdepth=120, args_template=1028, nargs=1, args=0x7fffffff9f68)
    at bytecode.c:919
#22 0x00000000005c16b2 in funcall_lambda (fun=18997477, nargs=1, 
    arg_vector=0x7fffffff9f60) at eval.c:2983
#23 0x00000000005c11a7 in Ffuncall (nargs=2, args=0x7fffffff9f58)
    at eval.c:2864
#24 0x0000000000600e44 in exec_byte_code (bytestr=21918129, vector=17903693, 
    maxdepth=16, args_template=1028, nargs=1, args=0x7fffffffa4a0)
    at bytecode.c:919
#25 0x00000000005c16b2 in funcall_lambda (fun=17919557, nargs=1, 
    arg_vector=0x7fffffffa498) at eval.c:2983
#26 0x00000000005c11a7 in Ffuncall (nargs=2, args=0x7fffffffa490)
    at eval.c:2864
#27 0x0000000000600e44 in exec_byte_code (bytestr=21918449, vector=17903597, 
    maxdepth=20, args_template=1028, nargs=1, args=0x7fffffffa9e0)
    at bytecode.c:919
#28 0x00000000005c16b2 in funcall_lambda (fun=17903645, nargs=1, 
    arg_vector=0x7fffffffa9d8) at eval.c:2983
#29 0x00000000005c11a7 in Ffuncall (nargs=2, args=0x7fffffffa9d0)
    at eval.c:2864
#30 0x0000000000600e44 in exec_byte_code (bytestr=14339425, vector=19017693, 
    maxdepth=16, args_template=0, nargs=0, args=0x7fffffffaf10)
    at bytecode.c:919
#31 0x00000000005c16b2 in funcall_lambda (fun=19017861, nargs=0, 
    arg_vector=0x7fffffffaf10) at eval.c:2983
#32 0x00000000005c11a7 in Ffuncall (nargs=1, args=0x7fffffffaf08)
    at eval.c:2864
#33 0x0000000000600e44 in exec_byte_code (bytestr=14364257, vector=19207309, 
    maxdepth=4, args_template=0, nargs=0, args=0x7fffffffb438)
    at bytecode.c:919
#34 0x00000000005c16b2 in funcall_lambda (fun=19308733, nargs=0, 
    arg_vector=0x7fffffffb438) at eval.c:2983
#35 0x00000000005c11a7 in Ffuncall (nargs=1, args=0x7fffffffb430)
    at eval.c:2864
#36 0x00000000005bfa48 in eval_sub (form=13338950) at eval.c:2157
#37 0x00000000005bdd6a in internal_lisp_condition_case (var=14018162, 
    bodyform=13338950, handlers=13339046) at eval.c:1323
#38 0x0000000000601ff5 in exec_byte_code (bytestr=21623585, vector=19198157, 
    maxdepth=64, args_template=1028, nargs=1, args=0x7fffffffbc48)
    at bytecode.c:1169
#39 0x00000000005c16b2 in funcall_lambda (fun=16683157, nargs=1, 
    arg_vector=0x7fffffffbc40) at eval.c:2983
#40 0x00000000005c11a7 in Ffuncall (nargs=2, args=0x7fffffffbc38)
    at eval.c:2864
#41 0x0000000000600e44 in exec_byte_code (bytestr=21665569, vector=18963773, 
    maxdepth=68, args_template=2052, nargs=1, args=0x7fffffffc1a8)
    at bytecode.c:919
#42 0x00000000005c16b2 in funcall_lambda (fun=16684125, nargs=1, 
    arg_vector=0x7fffffffc1a0) at eval.c:2983
#43 0x00000000005c11a7 in Ffuncall (nargs=2, args=0x7fffffffc198)
    at eval.c:2864
#44 0x0000000000600e44 in exec_byte_code (bytestr=10789089, vector=10789125, 
    maxdepth=8, args_template=0, nargs=0, args=0x7fffffffc6d0)
    at bytecode.c:919
#45 0x00000000005c16b2 in funcall_lambda (fun=10789037, nargs=0, 
    arg_vector=0x7fffffffc6d0) at eval.c:2983
#46 0x00000000005c11a7 in Ffuncall (nargs=1, args=0x7fffffffc6c8)
    at eval.c:2864
#47 0x00000000005c08c7 in apply1 (fn=20569570, arg=12757298) at eval.c:2581
#48 0x00000000005b9cd3 in Fcall_interactively (function=20569570, 
    record_flag=12757298, keys=12792317) at callint.c:378
#49 0x00000000005c1014 in Ffuncall (nargs=4, args=0x7fffffffc9f8)
    at eval.c:2822
#50 0x0000000000600e44 in exec_byte_code (bytestr=10183985, vector=10184021, 
    maxdepth=52, args_template=4100, nargs=1, args=0x7fffffffcf60)
    at bytecode.c:919
#51 0x00000000005c16b2 in funcall_lambda (fun=10183941, nargs=1, 
    arg_vector=0x7fffffffcf58) at eval.c:2983
#52 0x00000000005c11a7 in Ffuncall (nargs=2, args=0x7fffffffcf50)
    at eval.c:2864
#53 0x00000000005c096c in call1 (fn=12801186, arg1=20569570) at eval.c:2614
#54 0x0000000000531592 in command_loop_1 () at keyboard.c:1556
#55 0x00000000005bdecd in internal_condition_case (
    bfun=0x530eab <command_loop_1>, handlers=12808898, 
    hfun=0x5307bd <cmd_error>) at eval.c:1354
#56 0x0000000000530c05 in command_loop_2 (ignore=12757298) at keyboard.c:1174
#57 0x00000000005bd6df in internal_catch (tag=12804834, 
    func=0x530bdf <command_loop_2>, arg=12757298) at eval.c:1118
#58 0x0000000000530bb3 in command_loop () at keyboard.c:1153
#59 0x00000000005303b8 in recursive_edit_1 () at keyboard.c:777
#60 0x0000000000530525 in Frecursive_edit () at keyboard.c:845
#61 0x000000000052e550 in main (argc=3, argv=0x7fffffffd438) at emacs.c:1643

Lisp Backtrace:
  "message" (0xffff8338)
  "byte-compile-file-form-defmumble" (0xffff88b0)
0x1212ee8 PVEC_COMPILED
0x121e030 PVEC_COMPILED
0x121e060 PVEC_COMPILED
  "byte-compile-file-form-defalias" (0xffff9f60)
  "byte-compile-file-form" (0xffffa498)
  "byte-compile-toplevel-file-form" (0xffffa9d8)
0x1223080 PVEC_COMPILED
0x126a0b8 PVEC_COMPILED
  "funcall" (0xffffb430)
  "byte-compile-from-buffer" (0xffffbc40)
  "byte-compile-file" (0xffffc1a0)
  "emacs-lisp-byte-compile" (0xffffc6d0)
  "call-interactively" (0xffffca00)
  "command-execute" (0xffffcf58)


I don't have time to look into the rest of the things you asked right
now.

bug#16736: Compiling a Lisp file causes display to flash off and on

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 16736@debbugs.gnu.org
> Date: Sun, 16 Feb 2014 14:48:10 -0500
> 
> Eli Zaretskii wrote:
> 
> >> I put a break on x_clear_frame, and with emacs -Q, byte-compile-file on
> >> scheme.el triggers it.
> >
> > Can you show a backtrace from that breakpoint?
> 
> Easy enough.
> 
> #0  x_clear_frame (f=0x11cd8b8) at xterm.c:2909
> #1  0x00000000004ece00 in clear_frame (f=0x11cd8b8) at terminal.c:140
> #2  0x0000000000417f8f in redraw_frame (f=0x11cd8b8) at dispnew.c:2955
> #3  0x0000000000448e4d in clear_garbaged_frames () at xdisp.c:10935
> #4  0x0000000000448fb9 in echo_area_display (update_frame_p=1) at xdisp.c:10979
> #5  0x000000000044703a in message3_nolog (m=14191025) at xdisp.c:9987
> #6  0x0000000000446de9 in message3 (m=14191025) at xdisp.c:9929
> #7  0x00000000005b560f in Fmessage (nargs=3, args=0x7fffffff8338)
>     at editfns.c:3452

Thanks.  This clearly shows that the frame was marked as "garbaged",
which naturally requires its complete redrawing.

The question now becomes why it is marked garbaged.  It's possible
that the change in change_frame_size_1 is the reason, because the code
in that function does just that.

> I don't have time to look into the rest of the things you asked right
> now.

I hope you will some time soon, as I think we are zeroing in on the
culprit.

Thanks.

bug#16736: Compiling a Lisp file causes display to flash off and on

[Glenn Morris]

martin rudalics wrote:

> Does anything change when you set the frame's internal border width to
> zero?

emacs -Q -ib 0

seems the same.

> Does anything change when you disable the calls to
> x_clear_under_internal_border?

AFAICS, that function is not defined for me, since USE_X_TOOLKIT = 1.

bug#16736: Compiling a Lisp file causes display to flash off and on

[Glenn Morris]

Eli Zaretskii wrote:

> Can you put a breakpoint in change_frame_size_1, on line 5564:
>
>   SET_FRAME_COLS (f, new_cols); <<<<<<<<<<<<<<<<
>   FRAME_LINES (f) = new_lines;
>   FRAME_TEXT_WIDTH (f) = new_text_width;
>
> and see if that breakpoint breaks when you type "C-x 2" in *scratch*?

Yes, it does.

>   new_text_width
>   FRAME_TEXT_WIDTH (f)
>   new_root_width
>   old_root_width
>   FRAME_TEXT_TO_PIXEL_WIDTH (f, new_text_width)
>   FRAME_INTERNAL_BORDER_WIDTH (f)

640
640
672
672
674
1

bug#16736: Compiling a Lisp file causes display to flash off and on

[Glenn Morris]

Eli Zaretskii wrote:

>> In an attempt to follow your instructions, I put a break on dispnew.c:3045.
[...]
> I'm interested in seeing what happens the first time this breakpoint
> breaks after you type "C-x 2" in *scratch*.  (On my system, this is
> the only time it breaks after "C-x 2"; do you see something
> different?)

I do
  gdb> run -Q

and continue a few times until Emacs starts up. If I then select the
Emacs window with the mouse, it breaks twice, so I have to reselect the
gdb window to get it to continue, and then when I select the Emacs
window... Anyway, I can get around that by alt-tabbing back into Emacs.

> Are you saying that tracing into update_window_line and then
> update_text_area for these two, you see that the loop which starts at
> line 3598 ends with i's value smaller than
> desired_row->used[TEXT_AREA], and you see these 3 lines (3696 to 3698)
> being executed:

That does not seem to happen, no.
I have i = stop = 13 = desired_row->used[TEXT_AREA].

> Again, please trace all this upon the first time the breakpoint on
> line 3045 breaks after "C-x 2".

bug#16736: Compiling a Lisp file causes display to flash off and on

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 16736@debbugs.gnu.org,  rudalics@gmx.at
> Date: Sun, 16 Feb 2014 19:58:13 -0500
> 
> Eli Zaretskii wrote:
> 
> > Can you put a breakpoint in change_frame_size_1, on line 5564:
> >
> >   SET_FRAME_COLS (f, new_cols); <<<<<<<<<<<<<<<<
> >   FRAME_LINES (f) = new_lines;
> >   FRAME_TEXT_WIDTH (f) = new_text_width;
> >
> > and see if that breakpoint breaks when you type "C-x 2" in *scratch*?
> 
> Yes, it does.
> 
> >   new_text_width
> >   FRAME_TEXT_WIDTH (f)
> >   new_root_width
> >   old_root_width
> >   FRAME_TEXT_TO_PIXEL_WIDTH (f, new_text_width)
> >   FRAME_INTERNAL_BORDER_WIDTH (f)
> 
> 640
> 640
> 672
> 672
> 674
> 1

OK, then that's the root cause, right there: this function continues
to do this:

  adjust_frame_glyphs (f);
  calculate_costs (f);
  SET_FRAME_GARBAGED (f);
  f->resized_p = 1;

which marks the frame "garbaged" and requires its complete redisplay,
that starts with clearing it (as you have demonstrated in your
backtrace a few messages ago), and continues by redrawing the tool
bar.

Martin, any ideas why this happens in a toolkit build?  I don't
understand how come this condition:

  if (new_text_height == FRAME_TEXT_HEIGHT (f)
      && new_text_width == FRAME_TEXT_WIDTH (f)
      && new_root_width == old_root_width
      && (FRAME_PIXEL_HEIGHT (f) ==
	  FRAME_TEXT_TO_PIXEL_HEIGHT (f, new_text_height))
      && (FRAME_PIXEL_WIDTH (f) ==
	  FRAME_TEXT_TO_PIXEL_WIDTH (f, new_text_width)))
    return;

fails to cause the function to return.  The reason must be in the 2
last conditions, which you added in revision 115971.

Glenn, can you show the values of FRAME_PIXEL_HEIGHT (f) and
FRAME_PIXEL_WIDTH (f) in this scenario?

bug#16736: Compiling a Lisp file causes display to flash off and on

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 16736@debbugs.gnu.org
> Date: Sun, 16 Feb 2014 20:18:39 -0500
> 
> > Are you saying that tracing into update_window_line and then
> > update_text_area for these two, you see that the loop which starts at
> > line 3598 ends with i's value smaller than
> > desired_row->used[TEXT_AREA], and you see these 3 lines (3696 to 3698)
> > being executed:
> 
> That does not seem to happen, no.
> I have i = stop = 13 = desired_row->used[TEXT_AREA].

That figures: the problem is not that the rows differ, the problem is
that Emacs thinks the frame is garbaged, and redraws it
unconditionally.

bug#16736: Compiling a Lisp file causes display to flash off and on

[Glenn Morris]

Eli Zaretskii wrote:

>   if (new_text_height == FRAME_TEXT_HEIGHT (f)
>       && new_text_width == FRAME_TEXT_WIDTH (f)
>       && new_root_width == old_root_width
>       && (FRAME_PIXEL_HEIGHT (f) ==
> 	  FRAME_TEXT_TO_PIXEL_HEIGHT (f, new_text_height))
>       && (FRAME_PIXEL_WIDTH (f) ==
> 	  FRAME_TEXT_TO_PIXEL_WIDTH (f, new_text_width)))
>     return;

new_text_height = 570 = FRAME_TEXT_HEIGHT (f)
new_text_width = 640 = FRAME_TEXT_WIDTH (f)
new_root_width = 672 = old_root_width

FRAME_PIXEL_HEIGHT (f) = 605
FRAME_TEXT_TO_PIXEL_HEIGHT (f, new_text_height) = 572
new_text_height = 570

FRAME_PIXEL_WIDTH (f) = 674 = FRAME_TEXT_TO_PIXEL_WIDTH (f, new_text_width)
new_text_width = 640

bug#16736: Compiling a Lisp file causes display to flash off and on

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 16736@debbugs.gnu.org,  rudalics@gmx.at
> Date: Mon, 17 Feb 2014 02:45:40 -0500
> 
> Eli Zaretskii wrote:
> 
> >   if (new_text_height == FRAME_TEXT_HEIGHT (f)
> >       && new_text_width == FRAME_TEXT_WIDTH (f)
> >       && new_root_width == old_root_width
> >       && (FRAME_PIXEL_HEIGHT (f) ==
> > 	  FRAME_TEXT_TO_PIXEL_HEIGHT (f, new_text_height))
> >       && (FRAME_PIXEL_WIDTH (f) ==
> > 	  FRAME_TEXT_TO_PIXEL_WIDTH (f, new_text_width)))
> >     return;
> 
> new_text_height = 570 = FRAME_TEXT_HEIGHT (f)
> new_text_width = 640 = FRAME_TEXT_WIDTH (f)
> new_root_width = 672 = old_root_width
> 
> FRAME_PIXEL_HEIGHT (f) = 605
> FRAME_TEXT_TO_PIXEL_HEIGHT (f, new_text_height) = 572
> new_text_height = 570

Looks like FRAME_PIXEL_HEIGHT includes the tool bar, and is thus 33
pixels larger than we expect.  (What is f->tool_bar_height?)  But I
cannot find the place where we assign any value to FRAME_PIXEL_HEIGHT,
except in this very function, so I'm unsure where do those extra 33
pixels come from.

Glenn, if you put a breakpoint in change_frame_size_1 and then just
"run -Q", can you show all the calls you see until Emacs starts up,
including the arguments we pass to that function?  Here's what I see
on Windows:

  (gdb) break change_frame_size_1
  Breakpoint 3 at 0x100d809: file dispnew.c, line 5467.
  (gdb) r -Q
  Starting program: D:\gnu\bzr\emacs\trunk\src\emacs.exe -Q
  [New Thread 2272.0x13c0]
  [New Thread 2272.0x1790]
  [New Thread 2272.0x324]

  Breakpoint 3, change_frame_size_1 (f=0x394a9d8, new_width=80, new_height=160,
      pretend=true, delay=false, safe=false, pixelwise=true) at dispnew.c:5467
  5467      int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
  (gdb) c
  Continuing.

  Breakpoint 3, change_frame_size_1 (f=0x394a9d8, new_width=640,
      new_height=608, pretend=false, delay=true, safe=false, pixelwise=true)
      at dispnew.c:5467
  5467      int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
  (gdb)
  Continuing.

  Breakpoint 3, change_frame_size_1 (f=0x394a9d8, new_width=640,
      new_height=608, pretend=false, delay=true, safe=false, pixelwise=true)
      at dispnew.c:5467
  5467      int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
  (gdb)
  Continuing.

  Breakpoint 3, change_frame_size_1 (f=0x394a9d8, new_width=640,
      new_height=608, pretend=false, delay=false, safe=false, pixelwise=true)
      at dispnew.c:5467
  5467      int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
  (gdb)
  Continuing.

  Breakpoint 3, change_frame_size_1 (f=0x394a9d8, new_width=0, new_height=0,
      pretend=false, delay=false, safe=false, pixelwise=true) at dispnew.c:5467
  5467      int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
  (gdb)
  Continuing.

  Breakpoint 3, change_frame_size_1 (f=0x394a9d8, new_width=640,
      new_height=608, pretend=true, delay=false, safe=false, pixelwise=true)
      at dispnew.c:5467
  5467      int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
  (gdb)
  Continuing.

(The 640x608 size corresponds to the 80x35 text size I get (35
includes the mode line and the echo area), plus the equivalent of 3
text lines used for the tool bar.)

bug#16736: Compiling a Lisp file causes display to flash off and on

[martin rudalics]

 > Looks like FRAME_PIXEL_HEIGHT includes the tool bar, and is thus 33
 > pixels larger than we expect.  (What is f->tool_bar_height?)  But I
 > cannot find the place where we assign any value to FRAME_PIXEL_HEIGHT,
 > except in this very function, so I'm unsure where do those extra 33
 > pixels come from.

It's from update_various_frame_slots in widget.c.  If you comment that
out, the problem disappears.  But I don't know yet whether it's needed
elsewhere ...

martin

bug#16736: Compiling a Lisp file causes display to flash off and on

[Eli Zaretskii]

> Date: Mon, 17 Feb 2014 17:23:25 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Glenn Morris <rgm@gnu.org>, 16736@debbugs.gnu.org
> 
>  > Looks like FRAME_PIXEL_HEIGHT includes the tool bar, and is thus 33
>  > pixels larger than we expect.  (What is f->tool_bar_height?)  But I
>  > cannot find the place where we assign any value to FRAME_PIXEL_HEIGHT,
>  > except in this very function, so I'm unsure where do those extra 33
>  > pixels come from.
> 
> It's from update_various_frame_slots in widget.c.  If you comment that
> out, the problem disappears.  But I don't know yet whether it's needed
> elsewhere ...

If you mean this:

  FRAME_PIXEL_HEIGHT (f) = ew->core.height + x->menubar_height;

then does it mean that menubar_height is 33 pixels?  Sounds too much
to me.

bug#16736: Compiling a Lisp file causes display to flash off and on

[martin rudalics]

 > If you mean this:
 >
 >   FRAME_PIXEL_HEIGHT (f) = ew->core.height + x->menubar_height;
 >
 > then does it mean that menubar_height is 33 pixels?  Sounds too much
 > to me.

In change_frame_size I here have a FRAME_PIXEL_HEIGHT of 697 and a
new_text_height of 667.  f->output_data.x->menubar_height equals 28 and
there are two pixels to add for the default internal border.

martin

bug#16736: Compiling a Lisp file causes display to flash off and on

[Eli Zaretskii]

> Date: Mon, 17 Feb 2014 18:16:46 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: rgm@gnu.org, 16736@debbugs.gnu.org
> 
>  > If you mean this:
>  >
>  >   FRAME_PIXEL_HEIGHT (f) = ew->core.height + x->menubar_height;
>  >
>  > then does it mean that menubar_height is 33 pixels?  Sounds too much
>  > to me.
> 
> In change_frame_size I here have a FRAME_PIXEL_HEIGHT of 697 and a
> new_text_height of 667.  f->output_data.x->menubar_height equals 28 and
> there are two pixels to add for the default internal border.

OK, so it sounds like we need to make change_frame_size_1 consistent
with widget.c code.

bug#16736: Compiling a Lisp file causes display to flash off and on

[martin rudalics]

 > OK, so it sounds like we need to make change_frame_size_1 consistent
 > with widget.c code.

IMO the widget.c code is inherently absurd.  EmacsFrameResize processes
a resize request by calculating a text size from ew->core.height.  Then
it sets

   FRAME_PIXEL_HEIGHT (f) = ew->core.height + x->menubar_height;

and update_from_various_frame_slots inversely processes

   ew->core.height = FRAME_PIXEL_HEIGHT (f) - x->menubar_height;

where update_from_various_frame_slots is called only by
EmacsFrameInitialize.  Does anyone understand what this is good for?

martin

bug#16736: Compiling a Lisp file causes display to flash off and on

[Glenn Morris]

Eli Zaretskii wrote:

> (What is f->tool_bar_height?)

45

> Glenn, if you put a breakpoint in change_frame_size_1 and then just
> "run -Q", can you show all the calls you see until Emacs starts up,
> including the arguments we pass to that function?

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=80, new_height=150, 
    pretend=true, delay=false, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
    pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
    pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
    pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
    pretend=false, delay=false, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=0, new_height=0, 
    pretend=false, delay=false, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
    pretend=true, delay=false, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=537, 
    pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=537, 
    pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=80, new_height=38, 
    pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=537, 
    pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=537, 
    pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=571, 
    pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=571, 
    pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
    pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
    pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
    pretend=false, delay=false, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
    pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
    pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
    pretend=false, delay=false, safe=true, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
    pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
    pretend=false, delay=false, safe=true, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
    pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
    pretend=false, delay=false, safe=true, pixelwise=true) at dispnew.c:5467
5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
Continuing.

bug#16736: Compiling a Lisp file causes display to flash off and on

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 16736@debbugs.gnu.org,  rudalics@gmx.at
> Date: Mon, 17 Feb 2014 13:19:54 -0500
> 
> Eli Zaretskii wrote:
> 
> > (What is f->tool_bar_height?)
> 
> 45
> 
> > Glenn, if you put a breakpoint in change_frame_size_1 and then just
> > "run -Q", can you show all the calls you see until Emacs starts up,
> > including the arguments we pass to that function?
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=80, new_height=150, 
>     pretend=true, delay=false, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
>     pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
>     pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
>     pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
>     pretend=false, delay=false, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=0, new_height=0, 
>     pretend=false, delay=false, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
>     pretend=true, delay=false, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=537, 
>     pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=537, 
>     pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=80, new_height=38, 
>     pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=537, 
>     pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=537, 
>     pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=571, 
>     pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=571, 
>     pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
>     pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
>     pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
>     pretend=false, delay=false, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
>     pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
>     pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
>     pretend=false, delay=false, safe=true, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
>     pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
>     pretend=false, delay=false, safe=true, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
>     pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.
> 
> Breakpoint 3, change_frame_size_1 (f=0x11cd8b8, new_width=640, new_height=570, 
>     pretend=false, delay=false, safe=true, pixelwise=true) at dispnew.c:5467
> 5467	  int old_root_width = WINDOW_PIXEL_WIDTH (XWINDOW (FRAME_ROOT_WINDOW (f)));
> Continuing.

Thanks.

Martin, any idea what this dance with 570/537/571/570 sizes is about?

bug#16736: Compiling a Lisp file causes display to flash off and on

[Eli Zaretskii]

> Date: Mon, 17 Feb 2014 18:58:42 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: rgm@gnu.org, 16736@debbugs.gnu.org
> 
>  > OK, so it sounds like we need to make change_frame_size_1 consistent
>  > with widget.c code.
> 
> IMO the widget.c code is inherently absurd.  EmacsFrameResize processes
> a resize request by calculating a text size from ew->core.height.  Then
> it sets
> 
>    FRAME_PIXEL_HEIGHT (f) = ew->core.height + x->menubar_height;
> 
> and update_from_various_frame_slots inversely processes
> 
>    ew->core.height = FRAME_PIXEL_HEIGHT (f) - x->menubar_height;
> 
> where update_from_various_frame_slots is called only by
> EmacsFrameInitialize.  Does anyone understand what this is good for?

The latter part is not important, I think, because ew->core is not
used anywhere.

So the only important part here is setting FRAME_PIXEL_HEIGHT and
other fields of the frame struct.

widget.c is compiled only for X toolkits, right?  So I think making
update_various_frame_slots consistent with change_frame_size_1 when
USE_X_TOOLKIT will fix the problem.

bug#16736: Compiling a Lisp file causes display to flash off and on

[martin rudalics]

 > So the only important part here is setting FRAME_PIXEL_HEIGHT and
 > other fields of the frame struct.
 >
 > widget.c is compiled only for X toolkits, right?  So I think making
 > update_various_frame_slots consistent with change_frame_size_1 when
 > USE_X_TOOLKIT will fix the problem.

I defined out the assignments in update_various_frame_slots.  I saw no
other way because FRAME_PIXEL_HEIGHT inherently records the "old"
internal border width (that's all it does IIUC).  When the border width
changes, the text height remains unaltered, and I see no alternate means
to detect the change and redraw the frame appropriately.

martin

bug#16736: Compiling a Lisp file causes display to flash off and on

[martin rudalics]

 > Martin, any idea what this dance with 570/537/571/570 sizes is about?

The 570 ~> 537 seem caused by the 33 difference of Glenn's frame pixel
height w and w/o menubar + internal borders.  The 571 one is a mystery
to me.  Most of these changes seem caused by frequent calls of resize_cb
whose frequency is a mystery to me as well.  I also recall having seen
tooltip frames in here.

martin

bug#16736: Compiling a Lisp file causes display to flash off and on

[Eli Zaretskii]

> Date: Tue, 18 Feb 2014 12:02:41 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: rgm@gnu.org, 16736@debbugs.gnu.org
> 
>  > So the only important part here is setting FRAME_PIXEL_HEIGHT and
>  > other fields of the frame struct.
>  >
>  > widget.c is compiled only for X toolkits, right?  So I think making
>  > update_various_frame_slots consistent with change_frame_size_1 when
>  > USE_X_TOOLKIT will fix the problem.
> 
> I defined out the assignments in update_various_frame_slots.  I saw no
> other way because FRAME_PIXEL_HEIGHT inherently records the "old"
> internal border width (that's all it does IIUC).  When the border width
> changes, the text height remains unaltered, and I see no alternate means
> to detect the change and redraw the frame appropriately.

Thanks.  I see no problem with your changes.

bug#16736: Compiling a Lisp file causes display to flash off and on

[Glenn Morris]

martin rudalics wrote:

> I defined out the assignments in update_various_frame_slots.

Thanks, it doesn't flash now, so I'll close this.
(Please reopen, or open a new report, if you still think there are issues.)

bug#16736: Compiling a Lisp file causes display to flash off and on

[martin rudalics]

> Thanks.  I see no problem with your changes.

Thanks to you and Glenn for the forensics.

martin