Re: Display performance degradation

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 18 Dec 2009 17:47:22 +0100
> From: Jan_Djärv <jan.h.d@swipnet.se>
> Cc: mituharu@math.s.chiba-u.ac.jp, emacs-devel@gnu.org
> 
> Sure, but for each redisplay there is a lot of updating of other stuff, that 
> really doesn't need updating, like toll bars, menus and faces.

If you know that they don't need to be updated, sure.  But how do you
know that scroll bars and menus don't need to be updated?  E.g., for
menus, we have menu items whose sensitivity is dynamically
computed--how would you know in advance whether the conditions for
that changed or not?

> Redisplay is one thing, I'm not talking about that.  Rader the realization and 
> merging of faces that happens when redisplay is to be done.

Any new text that is being displayed, i.e. text that was not on the
screen during the previous redisplay, needs its faces to be computed
and merged.  If the text on the screen did not change, Emacs avoids
redisplay almost entirely.  If most of the text didn't change, only
the new or modified text is rendered, at least in the most frequent
cases.

> Hmm, faces are recomputed all the time.  If I start emacs like so:
> % ./emacs -Q ../etc/tutorials/TUTORIAL.ja
> 
> Emacs does 102 calls to merge_face_vectors.  This may be needed, I haven't 
> looked at this in detail.

Remember: each charset can potentially use a different font, i.e. a
different face.  But Emacs looks up any face it needs in the face
cache, before it decides to realize a new face.

> What is strange though, is that if I scroll to the bottom of the buffer, 
> another 62 calls to merge_face_vectors are done even if no face has changed.

Did you try to see where are those 62 calls done?