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.
I didn't notice this change because I'm using X fonts
+ #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);
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
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