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

[Eli Zaretskii <eliz@gnu.org>]

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