From: Eli Zaretskii <eliz@gnu.org>
To: Glenn Morris <rgm@gnu.org>
Cc: 16736@debbugs.gnu.org
Subject: bug#16736: Compiling a Lisp file causes display to flash off and on
Date: Sat, 15 Feb 2014 10:24:44 +0200 [thread overview]
Message-ID: <83iosgbx6b.fsf@gnu.org> (raw)
In-Reply-To: <2smwhurv74.fsf@fencepost.gnu.org>
> 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.
next prev parent reply other threads:[~2014-02-15 8:24 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-13 2:25 bug#16736: Compiling a Lisp file causes display to flash off and on Glenn Morris
2014-02-14 6:42 ` Glenn Morris
2014-02-14 7:29 ` Eli Zaretskii
2014-02-14 7:48 ` Glenn Morris
2014-02-15 8:24 ` Eli Zaretskii [this message]
2014-02-15 8:34 ` Eli Zaretskii
2014-02-15 21:28 ` Glenn Morris
2014-02-15 22:07 ` Glenn Morris
2014-02-16 10:31 ` martin rudalics
2014-02-16 16:46 ` Eli Zaretskii
2014-02-16 17:14 ` martin rudalics
2014-02-17 0:53 ` Glenn Morris
2014-02-16 16:22 ` Eli Zaretskii
2014-02-17 0:58 ` Glenn Morris
2014-02-17 5:14 ` Eli Zaretskii
2014-02-17 7:45 ` Glenn Morris
2014-02-17 15:42 ` Eli Zaretskii
2014-02-17 16:23 ` martin rudalics
2014-02-17 16:50 ` Eli Zaretskii
2014-02-17 17:16 ` martin rudalics
2014-02-17 17:27 ` Eli Zaretskii
2014-02-17 17:58 ` martin rudalics
2014-02-17 18:56 ` Eli Zaretskii
2014-02-18 11:02 ` martin rudalics
2014-02-18 18:08 ` Eli Zaretskii
2014-02-19 10:02 ` martin rudalics
2014-02-18 18:19 ` Glenn Morris
2014-02-17 18:19 ` Glenn Morris
2014-02-17 18:47 ` Eli Zaretskii
2014-02-18 11:03 ` martin rudalics
2014-02-16 16:17 ` Eli Zaretskii
2014-02-16 19:48 ` Glenn Morris
2014-02-16 21:04 ` Eli Zaretskii
2014-02-17 1:18 ` Glenn Morris
2014-02-17 5:15 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83iosgbx6b.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=16736@debbugs.gnu.org \
--cc=rgm@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).