From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: Display performance degradation Date: Thu, 17 Dec 2009 08:39:50 +0100 Message-ID: <4B29E046.8050107@swipnet.se> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: Quoted-Printable X-Trace: ger.gmane.org 1261035733 31558 80.91.229.12 (17 Dec 2009 07:42:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 17 Dec 2009 07:42:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: YAMAMOTO Mitsuharu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 17 08:42:06 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NLAzt-0000V4-Cq for ged-emacs-devel@m.gmane.org; Thu, 17 Dec 2009 08:42:05 +0100 Original-Received: from localhost ([127.0.0.1]:41405 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NLAzt-0005IR-Dy for ged-emacs-devel@m.gmane.org; Thu, 17 Dec 2009 02:42:05 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NLAxw-0004em-QL for emacs-devel@gnu.org; Thu, 17 Dec 2009 02:40:05 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NLAxr-0004cB-Cd for emacs-devel@gnu.org; Thu, 17 Dec 2009 02:40:03 -0500 Original-Received: from [199.232.76.173] (port=45719 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NLAxq-0004bu-UV for emacs-devel@gnu.org; Thu, 17 Dec 2009 02:39:59 -0500 Original-Received: from proxy3.bredband.net ([195.54.101.73]:36993) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NLAxl-0002Eo-PF for emacs-devel@gnu.org; Thu, 17 Dec 2009 02:39:58 -0500 Original-Received: from ipb1.telenor.se (195.54.127.164) by proxy3.bredband.net (7.3.140.3) id 4AD3E1BA01B572F6 for emacs-devel@gnu.org; Thu, 17 Dec 2009 08:39:52 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhFjAGVvKUtV4S1uPGdsb2JhbACBS5c2gkgBAQEBN7lzhC0EjSo X-IronPort-AV: E=Sophos;i="4.47,410,1257116400"; d="scan'208";a="16697832" Original-Received: from c-6e2de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.110]) by ipb1.telenor.se with ESMTP; 17 Dec 2009 08:39:52 +0100 Original-Received: from [10.225.40.66] (unknown [193.45.43.33]) by coolsville.localdomain (Postfix) with ESMTPSA id 9330B7FA07B; Thu, 17 Dec 2009 08:39:51 +0100 (CET) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 In-Reply-To: X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:118669 Archived-At: On 2009-12-17 03:49, YAMAMOTO Mitsuharu wrote: > 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. > > As an experiment, I tried restoring the following change, and then the > performance became comparable to 23.1. The basic question is why is this called so much? It is a fundamental=20 flaw in Emacs that makes it hard to add new stuff without degrading=20 performance. The core problem is that Emacs internally doesn't track=20 what is changed. So it re-evaluates faces, fonts, menus, toolbars and=20 so on, all the time before redisplay, and 99.99% of those times, nothing=20 has changed. So to speed things up, we have various caches to check if=20 things are the same as before. But these caches cause problems=20 elsewhere. For example, if a new font is added or if /etc/font.conf is=20 changed, Emacs must be restarted because caches prevents Emacs from=20 noticing the change. In particular, this cache prevents Emacs from picking up changes in=20 hintstyle or dpi or other font-related redering parameters. Emacs should to things all the way to get rid of this problem. Now,=20 when a menu for exampls is changed in lisp, the actual widgets on the=20 screen are not changed until later. So there is no connection between=20 the change and the update on the screen. So Emacs re-evaluates menus a=20 lot of times just to be sure, in case something changed at the lisp=20 level. Instead the lisp change should lead to a screen change at once.=20 That way we know that the menu is up to date and we don't have to=20 re-evaluate it. The same is true for faces, which I assume causes this=20 problem. I don't know if this particular problem can be worked around, probably=20 there is a way with different caching and/or status flags, but it will=20 be just another band-aid. The real problem is harder to fix. Jan D. > > 2009-11-17 Jan Dj=E4rv > > * font.c (font_open_entity): Do not use cache, it does not pick up new > fontconfig settings like hinting. > > *** 2975,2985 **** > --- 2987,3001 ---- > else if (CONSP (Vface_font_rescale_alist)) > scaled_pixel_size =3D pixel_size * font_rescale_ratio (entity); > > + #if 0 > + /* This doesn't work if you have changed hinting or any other param= eter. > + We need to make a new object in every case to be sure. */ > for (objlist =3D AREF (entity, FONT_OBJLIST_INDEX); CONSP (objlist= ); > objlist =3D XCDR (objlist)) > if (! NILP (AREF (XCAR (objlist), FONT_TYPE_INDEX)) > && XFONT_OBJECT (XCAR (objlist))->pixel_size =3D=3D pixel_size) > return XCAR (objlist); > + #endif > > val =3D AREF (entity, FONT_TYPE_INDEX); > for (driver_list =3D f->font_driver_list; > > The added comment implies that the simple removal of #if 0 causes > another problem for some cases, but I think creating a new font object > for each call is too much for the usual cases. Perhaps this part > needs some improvement. > > YAMAMOTO Mitsuharu > mituharu@math.s.chiba-u.ac.jp >