Re: Display performance degradation

[Kenichi Handa]

In article <address@hidden>, YAMAMOTO Mitsuharu <address@hidden> writes:

> I can observe significant display performance degradation on Emacs
> 23.1.90 compared with 23.1, especially when scrolling TUTORIAL.ja on a
> frame that uses the xft font backend.  I also observe the increase of
> the total number of xftfont_draw calls, and a string in a single font
> and color, which was originally displayed by one call, is now
> unnecessarily divided into smaller units.
[...]
> + #if 0
> +   /* This doesn't work if you have changed hinting or any other parameter.
> +      We need to make a new object in every case to be sure. */
>     for (objlist = AREF (entity, FONT_OBJLIST_INDEX); CONSP (objlist);
>          objlist = XCDR (objlist))
>       if (! NILP (AREF (XCAR (objlist), FONT_TYPE_INDEX))
>       && XFONT_OBJECT (XCAR (objlist))->pixel_size == pixel_size)
>         return  XCAR (objlist);
> + #endif
  
I didn't notice this change because I'm using X fonts
mainly.

In article <address@hidden>, "Jan D." <address@hidden> writes:

> The basic question is why is this called so much?

If it is not known, the above code should not be commented out.

> It is a fundamental 
> flaw in Emacs that makes it hard to add new stuff without degrading 
> performance.  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.  So to speed things up, we have various caches to check if 
> things are the same as before.  But these caches cause problems 
> elsewhere.

Those caches (including face-cache) are there because of the
current redisplay engine (and face handling).  So, without
fixing it (in your word, a fundamental flaw), those caches
should not be disabled.

> For example, if a new font is added or if /etc/font.conf is 
> changed, Emacs must be restarted because caches prevents Emacs from 
> noticing the change.

The problem of extremely slow display is the bigger problem
than it.

> In particular, this cache prevents Emacs from picking up changes in 
> hintstyle or dpi or other font-related redering parameters.

> 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. 
>   That way we know that the menu is up to date and we don't have to 
> re-evaluate it.  The same is true for faces, which I assume causes this 
> problem.

> I don't know if this particular problem can be worked around, probably 
> there is a way with different caching and/or status flags, but it will 
> be just another band-aid.  The real problem is harder to fix.

Then please enable the feature of making Emacs react to the
change of dpi, etc only after the workaroubnd is found or
the real problem is fixed.

---
Kenichi Handa
address@hidden