Re: Inefficient redisplay

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Date: Mon, 12 Apr 2010 00:34:05 -0400
> 
> I'm still playing around with my nhexl-mode attempt and I'm encournering
> some serious performance problems.  One of them seems to be linked to
> the fact that the redisplay code somehow seems to treat nhexl-mode's
> buffers as one single long-line.
> 
> This is probably because all the \n have a display property on them that
> makes them appear as an "␊" char.  The buffer's display does have
> line separators in the overlays's before-strings, but apparently the
> redisplay doesn't pay enough attention to them to notice that they can
> be used to stop the search for the beginning of a line.

What do you mean by ``stop the search''?  Redisplay does not search
for newlines, but when they are encountered (as part of normal
iteration through buffer text and any `display' properties and overlay
strings that are found along the way), it treats them as the end of
display line.  It doesn't (or shouldn't) matter that the newline comes
from an overlay as opposed to a buffer.  At least that's the theory.

Are you saying that in the following code fragment from display_line,
the main workhorse of displaying a single screen line, the condition
is never true in your case?

      /* Is this a line end?  If yes, we're also done, after making
         sure that a non-default face is extended up to the right
         margin of the window.  */
      if (ITERATOR_AT_END_OF_LINE_P (it))
        {
          int used_before = row->used[TEXT_AREA];

          row->ends_in_newline_from_string_p = STRINGP (it->object);

(There are a few more places where the code tests for the end of a
line.)

> One related problem (which can be witnessed firsthand from Elisp) is
> that all the text between point-min and the window's point is jit-locked
> (even though only the text visible in the window should need to be
> jit-locked).

I believe this is because of the following heuristics in jit-lock.el:

           ;; Decide which range of text should be fontified.
           ;; The problem is that START and NEXT may be in the
           ;; middle of something matched by a font-lock regexp.
           ;; Until someone has a better idea, let's start
           ;; at the start of the line containing START and
           ;; stop at the start of the line following NEXT.
           (goto-char next)  (setq next (line-beginning-position 2))
           (goto-char start) (setq start (line-beginning-position))

> This makes nhexl-mode completely unusable except on small buffers

I suggest, first of all, to understand why the display engine misses
the newlines you say you have in the before-strings.  The Emacs
display code is known to behave very unfriendly when lines are too
long, so my first advice would be not to do what hurts.