bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#16736: Compiling a Lisp file causes display to flash off and on
Date: Sun, 16 Feb 2014 18:17:32 +0200

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]