From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andrew Maguire Newsgroups: gmane.emacs.help Subject: Re: [h-e-w] Emacs Resource (GDI) Leak on Windows Date: Fri, 03 Feb 2006 15:51:06 +0000 Message-ID: <43E37BEA.1020706@ps.ge.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1138999407 28066 80.91.229.2 (3 Feb 2006 20:43:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 3 Feb 2006 20:43:27 +0000 (UTC) Cc: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Feb 03 21:43:20 2006 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F57lt-00034z-Gu for geh-help-gnu-emacs@m.gmane.org; Fri, 03 Feb 2006 21:43:10 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F57p3-00077n-Ul for geh-help-gnu-emacs@m.gmane.org; Fri, 03 Feb 2006 15:46:26 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F55GT-0004NO-VB for help-gnu-emacs@gnu.org; Fri, 03 Feb 2006 13:02:34 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F53RB-00021D-VP for help-gnu-emacs@gnu.org; Fri, 03 Feb 2006 11:05:37 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F53GY-0008GX-PJ for help-gnu-emacs@gnu.org; Fri, 03 Feb 2006 10:54:31 -0500 Original-Received: from [194.216.182.133] (helo=ultimate.Smallworld.co.uk) by monty-python.gnu.org with esmtp (Exim 4.52) id 1F53FV-00048l-4e; Fri, 03 Feb 2006 10:53:25 -0500 Original-Received: from ps.ge.com by ultimate.Smallworld.co.uk (8.8.8+Sun/SWW-2.8-Gateway) id PAA07451; Fri, 3 Feb 2006 15:50:55 GMT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us Original-To: jasonr@gnu.org X-Mailman-Approved-At: Fri, 03 Feb 2006 13:51:55 -0500 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:32976 Archived-At: This GDI leakage is still an issue - Emacs 21.2/3 It appears to be directly related to the display of any modified fonts, italic, bold etc. For examnple, 1. start up a completely plain Emacs --no-site-file. 2. Run Windows Task Manager and set it to display GDI object usage. 3. M-x list-faces-display 4. SCroll the buffer up and down a lot and GDI object count increases. 5. Make the *Faces* buffer editable and remove all lines whose font is not simply a modified foreground a background colour, i.e. italic bold, fixed-pitch, variable-pitch, mode-line and tool-bar. 6. Repeat scrolling up and down to force redisplay of the screen and not that although the GDI count may go up by 1 or 2 after you stop scrolling the extra GDI resource is released leaving with the same number as before. The GDI usage is also directly related to the font used also. By default Emacs, uses Courier New, Regular, 10pt. If you remove all the modified fonts above except italic. Then you will find that GDI objects will leak if Courier New is used but NOT if Courier is used. It appears to be related to the method Emacs uses to generate these modified forms of the main font. Courier New apears to be a TrueType font but Courier is not - whether that has any difference I am not sure. I hope these observations will be able to help find a fix for this problem. It is a particular pain for Modes using font-lock when font-lock is configured to use bold and italic fonts. As has been mentioned before in this thread, the GDI object resource is a strictly limited resource on Windows and when Windows approaches that limit the display code Windows uses to update the screen goes haywire, often blatting screen data in the top left portion of the screen. Andrew Maguire