From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: Analysis of redisplay performance on Windows Date: Sat, 26 Jul 2008 23:07:26 -0400 Message-ID: <87od4kuis1.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1217128063 24442 80.91.229.12 (27 Jul 2008 03:07:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Jul 2008 03:07:43 +0000 (UTC) Cc: emacs-devel@gnu.org To: Jason Rumney Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 27 05:08:32 2008 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 1KMwca-0004gM-2z for ged-emacs-devel@m.gmane.org; Sun, 27 Jul 2008 05:08:32 +0200 Original-Received: from localhost ([127.0.0.1]:39613 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KMwbf-0001WQ-Sc for ged-emacs-devel@m.gmane.org; Sat, 26 Jul 2008 23:07:35 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KMwbb-0001UR-96 for emacs-devel@gnu.org; Sat, 26 Jul 2008 23:07:31 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KMwbZ-0001TR-OD for emacs-devel@gnu.org; Sat, 26 Jul 2008 23:07:30 -0400 Original-Received: from [199.232.76.173] (port=54622 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KMwbZ-0001TI-Jf for emacs-devel@gnu.org; Sat, 26 Jul 2008 23:07:29 -0400 Original-Received: from c-24-63-201-57.hsd1.ma.comcast.net ([24.63.201.57]:16289 helo=furry) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KMwbW-0006vb-H1; Sat, 26 Jul 2008 23:07:26 -0400 Original-Received: by furry (Postfix, from userid 1000) id 08BE5C059; Sat, 26 Jul 2008 23:07:26 -0400 (EDT) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) 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:101573 Archived-At: Jason Rumney writes: > The redisplay performance problems on Windows seem to be mostly caused > by the left_overwriting and right_overwriting functions. These functions > analyse all glyphs, one by one, before and after (respectively) the > current glyph string on the same row to see if the glyphs overlap the > current glyph string. > > To determine the overlap for each glyph, it is necessary to encode it > into a glyph code point in the font used to display it, then measure its > text extents. Even with caching of the text extents, the Windows code > is still especially slow here because of the encoding to glyph code points. > > Currently we cache glyph code points at the glyph_string level. Perhaps > caching them at the glyph row level would help, as we could then reuse > them after we have finished with the glyph string. Alternatively we > could keep all the glyph strings for the row until we are finished so we > could use glyph code points and other information from there. This might > reduce the number of iterations we need to find the left and right > overwriting glyphs, since we can check the glyph strings for overlaps > first, and only check the glyphs inside glyph strings that overlap. > > There may also be a problem with the setting of > row->contains_overlapping_glyphs_p on Windows. The above functions > should only be called when that is set, but after inserting debugging > code I can see them being called frequently even when using fonts that > contain no overlapping glyphs (confirmed by further debugging code in > w32font_text_metrics). Thanks for looking into this, Jason. But I don't understand why the problem of left_overwriting and right_overwriting, if that's indeed the culprit, would be specific to Windows. These functions are called in the platform-independent redisplay code. Or is it much more expensive to look up glyph code points in fonts on Windows, compared to GNU/Linux?