[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16526: 24.3.50; scroll-conservatively & c-mode regression
From: |
Eli Zaretskii |
Subject: |
bug#16526: 24.3.50; scroll-conservatively & c-mode regression |
Date: |
Sat, 01 Feb 2014 12:41:51 +0200 |
> 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.
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression,
Eli Zaretskii <=