Re: Inefficient redisplay

[Stefan Monnier]

> I started looking at what nhexl-mode does, and I'm puzzled by the
> logic of its design.  Why do you arrange for nhexl-jit to be called
> via fontification-functions, if you also have it on post-command-hook?
> Is one of them a remnant of an idea that was rejected? if so, which
> one?  If you really do need both, can you explain why?

AFAIK I need both: nhexl-jit is used to add the hexdump lines to all the
text that's displayed, whereas the post-command-hook is used to update
the cursor highlighting (which is why it only updates the overlays on
the old point position and the new point position).

I guess the cursor updating could be more efficient by only changing the
`face' text-properties on the overlay's before strings rather than
building new overlays from scratch.  I haven't tried that yet, but I'm
afraid this will lead to problems because the redisplay code won't
notice that a before-string was modified so it may forget to redisplay
the corresponding part of the screen.

> If invoking nhexl-jit via fontification-functions is really needed,
> then where do you expect redisplay to invoke it?  IOW, if you make
> assumptions regarding the value of START and END arguments passed to
> nhexl-jit by redisplay, what are those assumptions?

I don't make any particular assumptions about start and end (at least
not consciously).

>> The behavior I see seems consistent with a situation where the redisplay
>> "doesn't see" the newlines in the before-strings
> I don't see any sign that redisplay "doesn't see" the newlines.

I only say that because the performance behavior is very similar to what
we get in long-single-line buffers.

> The mere fact that you see several lines on the screen is the proof
> that redisplay did see the newlines: that's how it knows that one line
> ends and another begins.

Yes, clearly it sees them in this sense.  


        Stefan