From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Herman, Geza" Newsgroups: gmane.emacs.devel Subject: Re: Rendering performace vs. line-spacing Date: Fri, 8 Jan 2021 14:46:10 +0100 Message-ID: <47ad132e-a6e4-6f10-e952-c490bf93c71e@gmail.com> References: <5f7dd7c3-ec7d-ffd5-76af-1a5ee5177d07@gmail.com> <83a6tjk485.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8152"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 08 14:47:19 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 1kxs6o-000211-5r for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Jan 2021 14:47:18 +0100 Original-Received: from localhost ([::1]:50860 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxs6n-0001Zw-5r for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Jan 2021 08:47:17 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45858) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxs5n-00017g-Fq for emacs-devel@gnu.org; Fri, 08 Jan 2021 08:46:15 -0500 Original-Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]:35033) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kxs5l-0005Sy-Tc for emacs-devel@gnu.org; Fri, 08 Jan 2021 08:46:15 -0500 Original-Received: by mail-ej1-x62c.google.com with SMTP id q22so14646392eja.2 for ; Fri, 08 Jan 2021 05:46:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:cc:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=UOfa5+gZrhaO7hoFjjiw4fWQwBGgiUc7ki1cqDj/Jxs=; b=f29hCO2gr6cY24HjKoNmXIRoCQbjsQ/M3AzqnkZH9wWVeEtrZBEY4VCg/MoB4Kcdm2 xbAxmaTipY3SyUxPvMq/LtSGpcWz0xyknKnvb8p9l3ZGl1lNFY5XzIFfEvgJiiMvVmR/ Stl46fjJOpeEG0zJVMNYbXMAjhGxgX62jUvNWaPjNBA8rDpHgMv3MjnAEwlizRnIathh vJPoI+LhZQQJXbVQHK/fzcy2x16XeTcg8nphizuMox+VAMva6cUizXqtj4cfrSs4plxJ PJrGxmVbJXDp8ZU0Whw3UoCv/GejHXrgsrpymx0RctwNAxCgRchj0oRIdq+7GYGQipBn oX3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=UOfa5+gZrhaO7hoFjjiw4fWQwBGgiUc7ki1cqDj/Jxs=; b=puIVyVlaa/vIT/1l/QBEnwBVvausBHHFCltAEAObtAGt7KcvOW7VEcOb2w6Jkzkkwq lpC76ipN0NGaxJqYuDXlTEu4tO6XOgizw2aDn48/0T0pUlOXU18ADDUMMxrL6WmyJK2b XCG8BmuJfPSUqRE6BP4SeoP1lLRE8EtAMNjxm65XqSt82HVQqOG9STNp2nwKekcPKHe9 zx1IXPrSWt8egW/i+G+jSbEGGmDAyGcRKlMr64w4XGcqEcC5AkjBCjAIiOxK+t1wtZUm 3K4ParfWv2feANzh7TCH65FzP6ncnHOBM9hXXETys96gbGVHSC0MI27hOjlCBEJxewAj wdoA== X-Gm-Message-State: AOAM5332OzGPGsZG7uQ21/VGS02HyTKLXostboENZwrU4Rfc/7JiEOP2 xvp/2TggLld2WYkwIVN00mNIHWqXk0ieUA== X-Google-Smtp-Source: ABdhPJy9NT2S088Iy20KRzpSWa81I4X6pj0+KeYEVWmH2A6eUEr99PW46UOgn6a6jhVCXpezawLhOg== X-Received: by 2002:a17:906:2681:: with SMTP id t1mr2673413ejc.29.1610113572105; Fri, 08 Jan 2021 05:46:12 -0800 (PST) Original-Received: from [10.0.50.117] (catv-89-134-149-1.catv.broadband.hu. [89.134.149.1]) by smtp.gmail.com with ESMTPSA id i8sm3779508eds.72.2021.01.08.05.46.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Jan 2021 05:46:11 -0800 (PST) In-Reply-To: <83a6tjk485.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::62c; envelope-from=geza.herman@gmail.com; helo=mail-ej1-x62c.google.com X-Spam_score_int: 5 X-Spam_score: 0.5 X-Spam_bar: / X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=1.769, MISSING_HEADERS=1.021, NICE_REPLY_A=-0.241, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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:262743 Archived-At: On 2021-01-08 13:22, Eli Zaretskii wrote: >> From: Herman, Géza >> Date: Fri, 8 Jan 2021 12:34:53 +0100 >> >> I noticed that emacs's performance can depend on the font. For example, >> Consolas has a much worse performance (scrolling is sluggish) than >> BitStream Mono. I profiled emacs, and the main difference is >> "draw_glyphs". When emacs is slow (using consolas), this function takes >> 50-60% of CPU time (measured by "perf record -g"). When emacs is fast >> (using BitStream), this function takes only ~2-3%. >> >> I played with my font's ascent and descent settings to have more line on >> the screen (as emacs doesn't support negative line-spacing). Originally, >> "draw_glyphs" takes 2-3% with my font. But if I decrease the height of >> the font by modifying ascent/descent, then the same thing happens: >> draw_glyphs takes 50-60% CPU time. If I set line-spacing to 2, >> draw_glyphs become normal, 2-3% CPU time. >> >> > When screen lines can overlap, we have code to handle that, and it > indeed could slow down redisplay. However, you are saying that you > _decrease_ ascent/descent, and I'm not sure I understand how could > that cause overlaps? In fontforge, I made these values smaller. So, this causes that emacs will display the font as if line-spacing were negative. So, lines start to overlap, because the actual height of the glyph doesn't change, but the vertical spacing between them is smaller. > In any case, I suggest to profile the code with perf, and see which > parts of the display code (below draw_glyphs) take those cycles with > the problematic font(s). Then we will see which part is the culprit, > and could take it from there. I did a perf record with emacs -Q, the results are better than my full configuration, but the difference is still there (now I see that there is a function which has a telling name about overlap: gui_fix_overlapping_area): - 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. It's not a big deal of course (otherwise emacs works OK, it's just the scrolling which is not smooth).