bug#14838: 24.3.50; repeating next-line or previous-line is broken

[Stephen Berman]

On Thu, 11 Jul 2013 22:16:00 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Jan Djärv <jan.h.d@swipnet.se>,  14838@debbugs.gnu.org
>> Date: Thu, 11 Jul 2013 20:51:42 +0200
>> 
>> Here are the top 200 lines of another profile (not identical to the one
>> I posted previously, but similar), which account for 99% of the CPU
>> time.  Is this saying that 70% of CPU time is spent in line-move-partial
>> (and 82% in aref)?
>
> I don't believe the aref part.  I think the real culprit is font-info.
> Let's conduct an experiment: if you modify default-font-height so that
> it always just calls frame-char-height, does the problem go away?

Yep, that it does.  And no trace messages are emitted.  So it seems some
fonts are sensitive to this distinction and others aren't.  What is the
crucial difference?

>> >> vs 0 dlh 14 this nil rowh 13 rbot 1 py 0 vpos 32 last 31.0
>> >> 2
>> >> 
>> >> and nothing else.
>> >
>> > The "py 0" part is very strange.  "py" is the vertical coordinate of
>> > point in screen line units.  Since this was with C-n, I expect py
>> > never to be less than half the screen height, which is 16.  How come
>> > it is zero, i.e. point is in the first line?  Can you step through
>> > line-move-partial in Edebug and see what is going on there?
>> 
>> If I instrument line-move-partial and type `C-n', I see py = 0 on the
>> first line and it increases by 1 on each subsequent line.  I have no
>> idea why *Messages* only showed a value of 0 for py; could it be that
>> the messages were overwritten when the CPU load hit 90%?
>
> Could be, since the messages are produced as part of redisplay.
>
> Can you show the trace messages from when the CPU is not yet 100%
> busy, and Emacs can still keep up with scrolling?

There are no trace messages while scrolling is normal; only after
redisplay stops (with >90% CPU load) and then recovers do the messages
appear, and they are all as above, with py=0.  I verified this by adding
a counter to the messages, and the first message emitted, with count=1,
shows py=0, as do all subsequent (none are overwritten).

Steve Berman