bug#16526: 24.3.50; scroll-conservatively & c-mode regression

[Eli Zaretskii]

> Date: Thu, 30 Jan 2014 19:58:17 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: acm@muc.de, 16526@debbugs.gnu.org
> 
>  > It takes about 11 sec here.  But reverting the patch doesn't change
>  > this timing, I still get 11 sec.
> 
> But it does take longer with a maximized window?

Yes, it does.

> If so, do you have an explanation?

Those 11 seconds are spent inside 'recenter', which is called by
end-of-buffer:

  ;; If we went to a place in the middle of the buffer,
  ;; adjust it to the beginning of a line.
  (cond ((and arg (not (consp arg))) (forward-line 1))
        ((and (eq (current-buffer) (window-buffer))
              (> (point) (window-end nil t)))
         ;; If the end of the buffer is not already on the screen,
         ;; then scroll specially to put it near, but not at, the bottom.
         (overlay-recenter (point))
         (recenter -3))))  <<<<<<<<<<<<<<<<<<<<<<<<<<

Stepping through 'recenter', I see the following:

  . It treats GUI frames specially (and indeed, in "emacs -nw", I
    don't see this slowdown).  The special handling is that it
    attempts to find the window-start point that corresponds to the -3
    argument, by interpreting that argument as the number of pixels
    equivalent to 3 canonical-height lines.

  . To this end, 'recenter' calls move_it_vertically_backward with the
    -3 argument converted to pixels.  move_it_vertically_backward then
    tries to find that place, by simulating display.

  . As part of the display simulation, jit-lock-function is called
    (because we hit a buffer position which has a non-nil 'fontified'
    property) with a single argument: buffer position 948757.  This
    single call takes almost all of the 11 seconds.

When the frame is not maximized, the window height is smaller, so
'recenter' moves back a smaller amount of pixels, and calls
jit-lock-function at a different buffer position.  That call takes
only about 2 sec (still quite a lot, IMO).

Perhaps Alan could explain why the CC Mode fontification takes such a
long time for buffer position 948757.