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
> 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).