[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).
- bug#16736: Compiling a Lisp file causes display to flash off and on, (continued)
- bug#16736: Compiling a Lisp file causes display to flash off and on, Eli Zaretskii, 2014/02/17
- bug#16736: Compiling a Lisp file causes display to flash off and on, martin rudalics, 2014/02/17
- bug#16736: Compiling a Lisp file causes display to flash off and on, Eli Zaretskii, 2014/02/17
- bug#16736: Compiling a Lisp file causes display to flash off and on, martin rudalics, 2014/02/18
- bug#16736: Compiling a Lisp file causes display to flash off and on, Eli Zaretskii, 2014/02/18
- bug#16736: Compiling a Lisp file causes display to flash off and on, martin rudalics, 2014/02/19
- bug#16736: Compiling a Lisp file causes display to flash off and on, Glenn Morris, 2014/02/18
- bug#16736: Compiling a Lisp file causes display to flash off and on, Glenn Morris, 2014/02/17
- bug#16736: Compiling a Lisp file causes display to flash off and on, Eli Zaretskii, 2014/02/17
- bug#16736: Compiling a Lisp file causes display to flash off and on, martin rudalics, 2014/02/18
- bug#16736: Compiling a Lisp file causes display to flash off and on,
Eli Zaretskii <=
- bug#16736: Compiling a Lisp file causes display to flash off and on, Glenn Morris, 2014/02/16
- bug#16736: Compiling a Lisp file causes display to flash off and on, Eli Zaretskii, 2014/02/16
- bug#16736: Compiling a Lisp file causes display to flash off and on, Glenn Morris, 2014/02/16
- bug#16736: Compiling a Lisp file causes display to flash off and on, Eli Zaretskii, 2014/02/17