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: Mon, 21 Dec 2009 10:17:46 +0900 Message-ID: References: <4B2A5F92.9090008@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1261358293 27085 80.91.229.12 (21 Dec 2009 01:18:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Dec 2009 01:18: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 Mon Dec 21 02:18:05 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 1NMWuT-0000Mg-5F for ged-emacs-devel@m.gmane.org; Mon, 21 Dec 2009 02:18:05 +0100 Original-Received: from localhost ([127.0.0.1]:43065 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMWuS-0006rh-FN for ged-emacs-devel@m.gmane.org; Sun, 20 Dec 2009 20:18:04 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMWuM-0006pW-Eo for emacs-devel@gnu.org; Sun, 20 Dec 2009 20:17:58 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMWuI-0006lW-RT for emacs-devel@gnu.org; Sun, 20 Dec 2009 20:17:58 -0500 Original-Received: from [199.232.76.173] (port=59377 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMWuI-0006lL-FZ for emacs-devel@gnu.org; Sun, 20 Dec 2009 20:17:54 -0500 Original-Received: from mx1.aist.go.jp ([150.29.246.133]:46421) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMWuH-000210-Mt for emacs-devel@gnu.org; Sun, 20 Dec 2009 20:17:54 -0500 Original-Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id nBL1Hl3t025192; Mon, 21 Dec 2009 10:17:47 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id nBL1HlIx009932; Mon, 21 Dec 2009 10:17:47 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp3.aist.go.jp with ESMTP id nBL1Hk12019715; Mon, 21 Dec 2009 10:17:46 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1NMWuA-0003lT-SE; Mon, 21 Dec 2009 10:17:46 +0900 In-Reply-To: (message from YAMAMOTO Mitsuharu on Sat, 19 Dec 2009 11:56:47 +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:118746 Archived-At: In article , YAMAMOTO Mitsuharu writes: > While I was looking at font caching code, I found a part that seems to > be wrong, though it is not directly related to the original > performance issue. > Fclear_font_cache (in src/font.c): > 4484 val = XCDR (cache); > 4485 while (! NILP (val) > 4486 && ! EQ (XCAR (XCAR (val)), driver_list->driver->type)) > 4487 val = XCDR (val); > 4488 font_assert (! NILP (val)); > 4489 val = XCDR (XCAR (val)); > 4490 if (XINT (XCAR (val)) == 0) > 4491 { > 4492 font_clear_cache (f, XCAR (val), driver_list->driver); > 4493 XSETCDR (cache, XCDR (val)); > 4494 } > 4495 } > At line 4490, XCAR (val) is expected to be of type Lisp integer. But > it is also passed to font_clear_cache at line 4492, which seems to > expect the value of `val' as of line 4488 rather than the one assigned > at line 4489. Oops, Fclear_font_cache is a funciton I made for debugging, but I have forgotten to put it within #ifdef FONT_DEBUG ... #endif, and also forgotten to adjsut it for the other changes. In article , Andreas Schwab writes: > If the condition is ever true then Emacs crashes. I've checked in a > fix. Thank you! > But then, I don't think this function is ever more than a no-op > anyway, since as soon as NUM-FRAMES becomes zero the cache is cleared > automatically anyway. Right, so it exists just for debugging. But, I've just found that the new file font-setting.el calls it now. Ummm, I'm not sure it works while a frame is alive. I'll check the code again. --- Kenichi Handa handa@m17n.org