From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Rendering performace vs. line-spacing Date: Fri, 08 Jan 2021 16:35:32 +0200 Message-ID: <83zh1jijij.fsf@gnu.org> References: <5f7dd7c3-ec7d-ffd5-76af-1a5ee5177d07@gmail.com> <83a6tjk485.fsf@gnu.org> <47ad132e-a6e4-6f10-e952-c490bf93c71e@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32684"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: "Herman, Geza" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 08 15:36:06 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kxss1-0008NG-Au for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Jan 2021 15:36:05 +0100 Original-Received: from localhost ([::1]:58210 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxsrz-0003Hq-WA for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Jan 2021 09:36:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59820) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxsrU-0002p5-7k for emacs-devel@gnu.org; Fri, 08 Jan 2021 09:35:33 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37570) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxsrU-0006Zj-0e; Fri, 08 Jan 2021 09:35:32 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2233 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kxsrS-0004H9-S5; Fri, 08 Jan 2021 09:35:31 -0500 In-Reply-To: <47ad132e-a6e4-6f10-e952-c490bf93c71e@gmail.com> (geza.herman@gmail.com) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:262748 Archived-At: > Cc: emacs-devel@gnu.org > From: "Herman, Geza" > Date: Fri, 8 Jan 2021 14:46:10 +0100 > > - 27.75% draw_glyphs >       - 18.80% gui_fix_overlapping_area >          - 18.63% update_window >               update_window_tree >               update_frame >             - redisplay_internal >                - 10.33% read_char >                     read_key_sequence >                - 8.09% read_key_sequence >                     command_loop_1 >          + 0.17% draw_phys_cursor_glyph >       - 8.86% gui_write_glyphs >          - 7.93% update_window_line >               update_window >               update_window_tree >               update_frame >             - redisplay_internal >                + 4.51% read_char >                + 3.33% read_key_sequence >          + 0.93% update_window > > > With larger line-spacing, this function takes 0.86%: > >       0.86% >       - 0.76% gui_write_glyphs >            update_window_line >            update_window >            update_window_tree >            update_frame >          - redisplay_internal >             - 0.63% read_char >                  read_key_sequence >         0.10% draw_phys_cursor_glyph > > But the overall effect is that with the overlapping setting, scrolling > is sluggish. If there's no overlap, scrolling is smooth, so I think that > actually there's a larger difference than the additional 25% CPU usage. If screen lines overlap with the offending font, then the difference could be justified, because redrawing one screen line would require redrawing the two adjacent screen lines. I'm a bit surprised by the large performance hit, though, so maybe it's worth looking at the code which gets run in the slow case, to see maybe some unnecessary work we are doing in that case. Do you have very wide windows, per chance? Does the problem becomes smaller if you make your frames and windows narrower?