Re: Display performance degradation

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 17 Dec 2009 08:39:50 +0100
> From: "Jan D." <jan.h.d@swipnet.se>
> Cc: emacs-devel@gnu.org
> 
> The core problem is that Emacs internally doesn't track 
> what is changed.  So it re-evaluates faces, fonts, menus, toolbars and 
> so on, all the time before redisplay, and 99.99% of those times, nothing 
> has changed.

Unless you are talking specifically about fonts (where I'm almost
totally ignorant), the above is not really true.  The redisplay code
includes quite a few shortcuts that try to reuse large parts of
existing display, instead of redrawing it.

> Emacs should to things all the way to get rid of this problem.  Now, 
> when a menu for exampls is changed in lisp, the actual widgets on the 
> screen are not changed until later.  So there is no connection between 
> the change and the update on the screen.  So Emacs re-evaluates menus a 
> lot of times just to be sure, in case something changed at the lisp 
> level.  Instead the lisp change should lead to a screen change at once. 

I'm far from being an expert on this, but AFAIU, what you want is
impossible without a total redesign of one of the main features of
Emacs architecture: that Lisp code changes only the buffer text and
various attributes of buffer text, while redisplay happens
independently of that, when Emacs decides that ``it's a good time'' to
do that.

>   That way we know that the menu is up to date and we don't have to 
> re-evaluate it.

I think re-evaluation of menus is unrelated to redisplay.

> The same is true for faces, which I assume causes this problem.

Faces are not recomputed unless necessary.  Large portions of the
display engine try very hard to avoid recomputing faces as much as
possible, to the degree that sometimes you need to work very hard even
to see the code which recomputes faces in action, because the various
optimizations completely short-circuit it.