From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: Display performance degradation Date: Thu, 17 Dec 2009 21:24:49 +0900 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1261052719 20653 80.91.229.12 (17 Dec 2009 12:25:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 17 Dec 2009 12:25:19 +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 13:25:11 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 1NLFPn-00057J-SH for ged-emacs-devel@m.gmane.org; Thu, 17 Dec 2009 13:25:08 +0100 Original-Received: from localhost ([127.0.0.1]:59396 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NLFPn-0007zk-PW for ged-emacs-devel@m.gmane.org; Thu, 17 Dec 2009 07:25:07 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NLFPf-0007vz-7K for emacs-devel@gnu.org; Thu, 17 Dec 2009 07:24:59 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NLFPa-0007ok-QJ for emacs-devel@gnu.org; Thu, 17 Dec 2009 07:24:58 -0500 Original-Received: from [199.232.76.173] (port=51078 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NLFPa-0007oK-MM for emacs-devel@gnu.org; Thu, 17 Dec 2009 07:24:54 -0500 Original-Received: from mx1.aist.go.jp ([150.29.246.133]:54621) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NLFPa-0007Pm-1m for emacs-devel@gnu.org; Thu, 17 Dec 2009 07:24:54 -0500 Original-Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id nBHCOoIE012839; Thu, 17 Dec 2009 21:24:50 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp4.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id nBHCOnRj003373; Thu, 17 Dec 2009 21:24:49 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp4.aist.go.jp with ESMTP id nBHCOnLv020254; Thu, 17 Dec 2009 21:24:49 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1NLFPV-0005vj-4n; Thu, 17 Dec 2009 21:24:49 +0900 In-Reply-To: (message from YAMAMOTO Mitsuharu on Thu, 17 Dec 2009 11:49:01 +0900) X-detected-operating-system: by monty-python.gnu.org: Solaris 9 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:118672 Archived-At: In article , YAMAMOTO Mitsuharu 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 <4B29E046.8050107@swipnet.se>, "Jan D." 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 handa@m17n.org