GNU bug report logs - #14616
24.3.50; Excessive cursor movement on non-X Emacs

Previous Next

Full log

Message #35 received at 14616 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14616 <at> debbugs.gnu.org
Subject: Re: bug#14616: 24.3.50; Excessive cursor movement on non-X Emacs
Date: Fri, 19 Jul 2013 17:31:32 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>   Could you please attach a debugger to Emacs, after starting the
>   server, but before opening the TTY frame with emacsclient, and set a
>   breakpoint like this:
>
>    (gdb) set height 0
>    (gdb) break update_frame_1
>    (gdb) commands
>     > p force_p
>     > p inhibit_id_p
>     > continue
>     > end
>    (gdb)

Thanks for the recipe.

The first thing that I notice is that after starting Gnus, and letting
Gnus settle (so there's not screen updates at all), I get the following:

Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false)
    at dispnew.c:4445
4445      struct glyph_matrix *current_matrix = f->current_matrix;
$443 = true
$444 = false

Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false)
    at dispnew.c:4445
4445      struct glyph_matrix *current_matrix = f->current_matrix;
$445 = true
$446 = false

Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false)
    at dispnew.c:4445
4445      struct glyph_matrix *current_matrix = f->current_matrix;
$447 = true
$448 = false

Once per second.  So it seems like something is making the update fire
regularly, but not very intensively.  Nothing that I'm able to detect
happens on the screen -- I have no clocks or anything altering anything.

Now, for the real bug.  When I then select an article in Gnus, this
starts firing like crazy:

Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false)
    at dispnew.c:4445
4445	  struct glyph_matrix *current_matrix = f->current_matrix;
$16335 = true
$16336 = false

Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false)
    at dispnew.c:4445
4445	  struct glyph_matrix *current_matrix = f->current_matrix;
$16337 = true
$16338 = false

Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false)
    at dispnew.c:4445
4445	  struct glyph_matrix *current_matrix = f->current_matrix;
$16339 = true
$16340 = false

Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false)
    at dispnew.c:4445
4445	  struct glyph_matrix *current_matrix = f->current_matrix;
$16341 = true
$16342 = false

Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false)
    at dispnew.c:4445
4445	  struct glyph_matrix *current_matrix = f->current_matrix;
$16343 = true
$16344 = false

Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false)
    at dispnew.c:4445
4445	  struct glyph_matrix *current_matrix = f->current_matrix;
$16345 = true
$16346 = false


[...]

Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false)
    at dispnew.c:4445
4445	  struct glyph_matrix *current_matrix = f->current_matrix;
$17071 = true
$17072 = false

Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false)
    at dispnew.c:4445
4445	  struct glyph_matrix *current_matrix = f->current_matrix;
$17073 = true
$17074 = false

Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false)
    at dispnew.c:4445
4445	  struct glyph_matrix *current_matrix = f->current_matrix;
$17075 = true
$17076 = false


So it fired about er seven thousand times?

When Gnus selects an article in these groups, a lot of network traffic
is fired off as it uses `url-retrieve' to pre-fetch images.  So my
uninformed guess would be that something in the network code is telling
Emacs that the display is dirty and needs to be repainted.

Does this output tell you anything, or should I put the breakpoints
somewhere else?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.