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

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

bug#14616: 24.3.50; Excessive cursor movement on non-X Emacs


From: Eli Zaretskii
Subject: bug#14616: 24.3.50; Excessive cursor movement on non-X Emacs
Date: Fri, 19 Jul 2013 21:46:07 +0300

> From: Lars Magne Ingebrigtsen <address@hidden>
> Cc: address@hidden
> Date: Fri, 19 Jul 2013 17:31:32 +0200
> 
> 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.

I think these are just the routine redisplay cycles.  update_frame_1
is called as part of the last portion of redisplay: when Emacs has
decided what parts of the screen need to be redrawn and what they
should look like, and now it is about to compare that with what is
actually displayed in those parts, and redraw the different parts.

So the periodical calls to update_frame_1 is not a problem in itself.

> 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
> [...]
> 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 the screen stay unchanged during this time, or is something
changing, like images being displayed after they are fetched?

If you see such a frantic activity when nothing changes on the screen,
then this is indeed a bug.  In that case, set a breakpoint in
update_frame_line, and display its 2nd argument, like this:

 (gdb) break update_frame_line
 (gdb) commands
  > p vpos
  > continue
  > end
 (gdb)

The values of vpos will tell us which parts of the screen, in terms of
line numbers, Emacs tries to redraw.  That will give some clues about
where to look next.

Thanks.





reply via email to

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