From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 01:19:18 2023 Received: (at submit) by debbugs.gnu.org; 25 Feb 2023 06:19:18 +0000 Received: from localhost ([127.0.0.1]:38849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVntt-00010P-OZ for submit@debbugs.gnu.org; Sat, 25 Feb 2023 01:19:18 -0500 Received: from lists.gnu.org ([209.51.188.17]:46882) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVntr-00010B-QN for submit@debbugs.gnu.org; Sat, 25 Feb 2023 01:19:16 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVntm-0006GP-L7 for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2023 01:19:15 -0500 Received: from sonic314-49.consmr.mail.ne1.yahoo.com ([66.163.189.175]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pVntj-0003J9-W1 for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2023 01:19:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677305943; bh=qqSI2dk88nGkNtH+bzp+xJq0IwV+JMB0Rl6CB6xaH9o=; h=From:To:Subject:Date:References:From:Subject:Reply-To; b=lxLy/9MXzT0fUFKf0GIVysabhGf7FRlbg1FS4CQe549Fxyaje6UZ20fjznQ0Q5/MJqeAW8Y/Pts7Cu0mMuDWgN/aCDZvBjReLvLRyuObZZxX5Qne4/fM8vdR01s2ujxyM934jW7fuEbmwP8pNBNMHSh6cFpmoeu+RY6LLhLyUoUeCldBc/1LUNhPE4fnVryZF+kpk+dNaB3y3OTXKg20HMLxf/fIv58IdpocV2heuetMQE1wbfpC5FRhtC70FlwiIQWMIfGuwibOY9B1tkoJyZg1YrRSxaOownBi2zD++kBUovckxpFpxjT2Of9P2jgPoAQBKEffrO4Gx/HE2KX0wA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677305943; bh=ktOBVpMF4+jz5ik2E5HUCQJmkJpiqZV0mxy/ty5qebG=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=oR8HIYK0hpYCA4tt+QhWLXTSfo1f3gQ9xlklbRtLUJfzlKLWvoxHecuRXnlPWYdJ55/sDtCklr7cIaSNKJwGdhr20jUJrISSQvZl3xLrsx27N2D9jE9OYCuDiRXp5XZ2TI0FPaE3GUVzjmBX2c2TjQZJsoKJUv4N42BBDwbQ0PycdqvyCjTORXHlpWCXi7guSlQFwbGDMrIYpstaIAzaZiUxGaMl7REbHWoxZgoty3WzoWPX7wAO4OGGTBujXlfihZC+u6/p2RyjwGFF+1B26KjPALpJ5mknqLYAwUqngXA651Fv/ltr2pmDIl2yhI9RxrmrG7MPnugTnd92Pxr3OQ== X-YMail-OSG: X2IKISYVM1kxDGipIWVIVOaqjcF.5DF_L5bNoRV9rM_Qe.HURF848oYtmsotOFp VDUTbE0uTfHIXfh6uChHLeO554eDzRnksLrEq34520LxSb0vzwzYaM1yw_tdEMTi3s5RwX86MfHM 9N197Eg8UY8bxaPhM9xQAZ8301mECJSrGL_qd9sncOm.h7VJVv6uvq_FyowKPiVFqVAwpW2IY.Y5 Sd2j6xJKxYqBkfIe0oHHbRrrHH8h7eTu5Lz3k9xydFDyQ1DiPGwMyq9vM6Pt7TazuCgcsOzTMscT 9sr7bbHcx48VvXknirgz7p8j_Si74rVhOoDHjJpRb8UxqFfayuMkRsJnE7rdF1Lz0CuDSlzRQjQc XIw1gLmEeMx03lAEXMIIoMLynhRA85ensgAxS8rbkwHGveIPhHl8wPy77iiW1aUE_7C1VHRQlhU_ itIrF0OLHAM3Sr4PbaXypsw9UB7OXc1CPOmU87e_H9N4.cGh1wYHYgiBD0KjXbGuAXmtZUBmt8DZ CY6MrJ24YsAg6JEdfX_qe5VjWhVaKLc.9C3xAbmuqhicd4zZoI5TZhyy4mJIAo4WKusNlkJmKNwp k.uXJbfcYSvGasmCQWnnECf1_G_1yF4xLNyw0_rISvqZmh3lVpA20QSTV72RjAWarSW9h1oq1KHf RkBRnpcpG1Ef7Sth0vcxarwkUunHAEVxBmZyeObnXHUIzodwaR5yP1aF41EwYsnperxAhxcV7LE0 ze3jJ7.miUagVuGKtYX9eyfn4QJ2D_A1flq2m0Xt1TxD_4xWMHam4GY0qzBqudVkDkzkgG59wRyE asWciTHejGu6I.OH2UOMesPN1nnNDJLUFL.dvH7yqNz_NNwKidylGtl5AE83oJRVRr50X3ciyHCs yr0sXcgSdzCAVRH9QaeS3LiKH1dd4QCunQGObFlMoUGRiR7AL.DZoN6wc6d6jIq1sO9hXman1Btw Kb5Xh1Kc2FQEZ3jglmNJpDX_GpHcCCUioJkVI_Wpq_EuGsE5GQWIRr6V8udIPx93a07FIQ8s8iJR jNNWhxzalB2rdWzAgBiU3.qIN_.M.vNoQw2QMtGkCM82LvxebffLE_TUb55TMWzoLvKz9SPmk2W3 EtCQFFdMLUjnTAhasTVHyUORqv4cUsE.z.Ftj2RSS6Xrda2U2yxN4i1rz6AJbDCPuG92qD3f9Gvf 4QnV4nCRL3bTS0gkl5qEl7agPUA3iZe5vhDekh3EsB_4OxFLI9EqNcVNhQstWe0R1TztxNhDzr6_ OaE4hBT8edXixmaJI3WxALGcaWNSliVn4zms3UgsMTxJ1Ec6otzrMBy94G9bjwXRk84FUTQRR9AK wl_LBbfRjixOlYR86Hpeb7ctwcvpk6EAj2DFBuO7.9bxkkLxH1.Bl323gwC4hnT2OggETDptAaa8 6PmucHoe6e8LqpnRrqam7GRJjc.BLg6fCa7uMc1L1YVesowlC_SqfR9lVwEVBIMqKCMnzxNgWnnx yGh6IEdftkd0FOKIJM.VteMnxLDMXKPLVs0zFItSAM.Gc7Qh2Yr5Tu2OkWAJllUr5C6eUtm1ILAc O0AJ7Lv0p0uupYyWF7EPu4iMhRzfJ67oCOkXeUSh3owWIWoLJg9yHP4pXsheXNA2xRnjGLS5C78T 2bLaM5ThA2Nksr4DNYp7UdEO4LRbj8zotvdohJLT9cqKsqSLtxeeVdbgGMRZ2AJzlU02FBZlOVR6 vZbapBn_M0DzYrqg58K3Bia9bFcRp7iRGZzAqRXeLp.rvHucVVX7epGICD9qG86K1nROI7sp_0AB FMDlOsamUjWGyCRZuPZyhNIy1IQShvdntTcY50ixA1MtSPw8p86mhJ8KHevoYHJG_iv4wTy4gtTj jVzcWT0wLqSufMnVTKL5m2T.jH0egShJribq_ruFohI8.ioaFum8hfpIDw0rmtP33RA4eJrJ.tyy 3YAC1GlZkkiCuukwvh4avR1SfW7Zb3UKoVH0qlDUxOrDxipLShosnG98GcUz0QRxuK3s0ZTmTzn3 lIzs3n2niLdxi5OfoWLm3.t.LN_xQob936HMI0c7xsYRauID2IHBFwefuEUyWdHrBfyIzellQdg. G5BNkUX56y7kxLrWF..DUDiRiNwsqF2U3QXoKzgTcentBOMhlk17oDMK2JE4.RGtW0jOZijmSHju XV0mzKUoVZPi5ePTVVvXrqvT95jg7PxH.N0SSA1pqNNQIc38d4Lm5_DkZF50U9cc6_U2nmbL_pb6 qCPJHoegHIvHQnuVglk_lWHtfdJNdeNeuvBHdRpXFqAHrqbnVe7xY2GWckRG4xyskMtg- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Sat, 25 Feb 2023 06:19:03 +0000 Received: by hermes--production-sg3-9fc5746c8-nc5k6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7e9695a441c5a7248e88652e28574e3a; Sat, 25 Feb 2023 06:17:00 +0000 (UTC) From: Po Lu To: bug-gnu-emacs@gnu.org Subject: 30.0.50; excessive redisplay when the mini window is active Date: Sat, 25 Feb 2023 14:16:37 +0800 Message-ID: <878rgm46d6.fsf@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain References: <878rgm46d6.fsf.ref@yahoo.com> X-Mailer: WebService/1.1.21221 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 3143 Received-SPF: pass client-ip=66.163.189.175; envelope-from=luangruo@yahoo.com; helo=sonic314-49.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.6 (-) For some reason redisplay_internal will always update the mini window even if its buffer contents have not changed. I guess there is probably a missing optimization wrt to updating the echo area contents, and window_outdated does not take the echo area message into account: && (CHARPOS (tlbufpos) == ZV || FETCH_BYTE (BYTEPOS (tlbufpos)) == '\n')) /* Former continuation line has disappeared by becoming empty. */ goto cancel; else if (window_outdated (w) || MINI_WINDOW_P (w)) <============== { /* We have to handle the case of continuation around a wide-column character (see the comment in indent.c around line 1340). I am not sure that is why, however, so I can't just change that. Anyway, update_window_line does not draw anything since the contents of the glyph row do not change after redisplay, so that part is fine. The problem is that the redisplay will lead to update_window being called, and gui_update_window_end will always call display_and_set_cursor afterwards to display the cursor, which is not okay, as it generates a lot of X protocol traffic when redisplay is called and redisplays the mini-window. Now add to that a process generating a lot of output, and by doing so, calls to redisplay_preserve_echo_area, and you have an absurd number of X requests, enough to saturate any reasonable network connection. Here is a patch to resolve the problem by not redrawing the cursor when Emacs knows it is already there. I've not seen any ill effects so far, but the comment originally there seems to know better, so what are the cases where ``phys_cursor_on_p is 1 but the cursor has been erased''? Thanks. diff --git a/src/xdisp.c b/src/xdisp.c index c5c4321af77..39568bb6b1f 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -33333,12 +33333,21 @@ display_and_set_cursor (struct window *w, bool on, && new_cursor_width != w->phys_cursor_width))) erase_phys_cursor (w); - /* Don't check phys_cursor_on_p here because that flag is only set - to false in some cases where we know that the cursor has been - completely erased, to avoid the extra work of erasing the cursor - twice. In other words, phys_cursor_on_p can be true and the cursor - still not be visible, or it has only been partly erased. */ - if (on) + /* XXX: this previously read: + + Don't check phys_cursor_on_p here because that flag is only set + to false in some cases where we know that the cursor has been + completely erased, to avoid the extra work of erasing the + cursor twice. In other words, phys_cursor_on_p can be true and + the cursor still not be visible, or it has only been partly + erased. + + However, not checking this flag results in too much cursor redraw + if the mini-window is being redisplayed, since process output + results in calls to redisplay_internal, which always redisplays + the mini window regardless of whether or not its contents have + changed. */ + if (on && !w->phys_cursor_on_p) { w->phys_cursor_ascent = glyph_row->ascent; w->phys_cursor_height = glyph_row->height; From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 03:29:12 2023 Received: (at 61779) by debbugs.gnu.org; 25 Feb 2023 08:29:12 +0000 Received: from localhost ([127.0.0.1]:38956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVpvc-0004jj-7b for submit@debbugs.gnu.org; Sat, 25 Feb 2023 03:29:12 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50868) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVpvZ-0004jR-Tq for 61779@debbugs.gnu.org; Sat, 25 Feb 2023 03:29:10 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVpvU-0000dE-Kf; Sat, 25 Feb 2023 03:29:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=3kXs/UEWFMD83fz+1pF+uQ5bfe5CFkAyULlYoWVLRJc=; b=RRTEkhC/mCO3 kvjZZ49jq3eqf+dmyxZi7/qMmTnf1qLkqy+NYsV83cYO7XxmUm28HokTZRWdQ+JW00WRPkWOWaQbk J4qRWIXv39+DRazFY7SFSksWoFsdqucImoj9eLxGTQC1cu+AUPNpf9P1mv2pBZ7cKgMRogKLRzs+l apnUaQvMeY4+g+RMzDvebJn+TSRl38GGT7UWdknFFRdHRMOfQRH5l2km0CenhDQT1luolHq9UtefK UNwxOZpYGLIi1NV3yoeKNFzXjlxSWAoD92Z+RqXxg9Ny14s3OCrJsGBcXVnFQtfZ9m4lgsq3dkNOv dfm4J4O4BbKcLn9WB4tSKA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVpvU-0005IX-3y; Sat, 25 Feb 2023 03:29:04 -0500 Date: Sat, 25 Feb 2023 10:29:07 +0200 Message-Id: <83ilfqkv1o.fsf@gnu.org> From: Eli Zaretskii To: Po Lu In-Reply-To: <878rgm46d6.fsf@yahoo.com> (bug-gnu-emacs@gnu.org) Subject: Re: bug#61779: 30.0.50; excessive redisplay when the mini window is active References: <878rgm46d6.fsf.ref@yahoo.com> <878rgm46d6.fsf@yahoo.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61779 Cc: 61779@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 25 Feb 2023 14:16:37 +0800 > From: Po Lu via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > For some reason redisplay_internal will always update the mini window > even if its buffer contents have not changed. I guess there is probably > a missing optimization wrt to updating the echo area contents, and > window_outdated does not take the echo area message into account: > > && (CHARPOS (tlbufpos) == ZV > || FETCH_BYTE (BYTEPOS (tlbufpos)) == '\n')) > /* Former continuation line has disappeared by becoming empty. */ > goto cancel; > else if (window_outdated (w) || MINI_WINDOW_P (w)) <============== > { > /* We have to handle the case of continuation around a > wide-column character (see the comment in indent.c around > line 1340). > > I am not sure that is why, however, so I can't just change that. > Anyway, update_window_line does not draw anything since the contents of > the glyph row do not change after redisplay, so that part is fine. The > problem is that the redisplay will lead to update_window being called, > and gui_update_window_end will always call display_and_set_cursor > afterwards to display the cursor, which is not okay, as it generates a > lot of X protocol traffic when redisplay is called and redisplays the > mini-window. Now add to that a process generating a lot of output, and > by doing so, calls to redisplay_preserve_echo_area, and you have an > absurd number of X requests, enough to saturate any reasonable network > connection. > > Here is a patch to resolve the problem by not redrawing the cursor when > Emacs knows it is already there. I've not seen any ill effects so far, > but the comment originally there seems to know better, so what are the > cases where ``phys_cursor_on_p is 1 but the cursor has been erased''? This is okay for master, thanks. Btw, the code which tests MINI_WINDOW_P here: > && (CHARPOS (tlbufpos) == ZV > || FETCH_BYTE (BYTEPOS (tlbufpos)) == '\n')) > /* Former continuation line has disappeared by becoming empty. */ > goto cancel; > else if (window_outdated (w) || MINI_WINDOW_P (w)) <============== > { > /* We have to handle the case of continuation around a > wide-column character (see the comment in indent.c around > line 1340). is very old, dating back to the initial revision of xdisp.c before the Emacs 21 display engine changes, so maybe we should try removing that instead (assuming that it is related to the more general change regarding the cursor you want to install). From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 04:39:49 2023 Received: (at 61779) by debbugs.gnu.org; 25 Feb 2023 09:39:49 +0000 Received: from localhost ([127.0.0.1]:39042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVr1w-0006fc-RO for submit@debbugs.gnu.org; Sat, 25 Feb 2023 04:39:49 -0500 Received: from sonic305-47.consmr.mail.ne1.yahoo.com ([66.163.185.173]:44410) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVr1u-0006fN-Dm for 61779@debbugs.gnu.org; Sat, 25 Feb 2023 04:39:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677317979; bh=M/wV1r4OgM+u4xHyj0nwq2kcojl5icP424f+zoC3KbY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=cUr/fhUc54yoAzc/jagNwh2ucuJ8/QOouuAI2cthHFgp+8yTY3tXp3hbuxLRGiGEDDSIyHJEiO3S+qQt7Zf2fFjWc9e4e1yy1iR2jNG4oH5ohKUNPu1kC0i73M0IZV6dr8m+8lZecfgf/a+QSN5SFZ1YfLvUmDR7Zc7SfU/aOjuFhuOX4gFFAnn9T3dKSc/j6RAas3Ql7iZBqBZTIUxoT6OZ6u7HssXi3XdrocRDp8gUMHZ/iTvT6t+xBUHMVLeFlNmxf+a95MUXuf29wUcrhrOiGe17Q0k+y1KWH+mvvW39PakXQgV431izP3Ft1PSHH0qmO0GfE0T1tGQbJ5ow7Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677317979; bh=Pvsc1xKdaEZf/Zb2c43XsbyaDGtuBiRthGUUJtArQAH=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=nnbQhGKp/9VejhxRzwIRWA5UcTHRYDoA+rEflCrmXLpWe+XGgmsOSnRbgDMFaNaNqT8HAQUOsjxDYLXOGKsw2BvKuvFDee+FvdrLKA8IG8AOX4uG0C+yavrA8t4IvgOrUiWgvsaJsoo7QPjV2vUjnwvEPW1Xdza5d3bYd4DWXiqGDg/RAW+nQz2Z0jYKjBFSDHWxNQJ8uMEy+ZqXWxZPOKcoLyR09sMzaOCPxzpismaPM4nmn3BDqy+WLaRu6GvLTNyzPyPMTKVEKijHldzTCpr6lBZhxrraklAgy0JGjmf6zR4RT6x/16lZg+zgPvDOX5Nh2OO69OYFdo+PUPbT+g== X-YMail-OSG: uo4mp.cVM1m4Ps9Z_I.o.Al_SmkVcRB4o3Nvgj9TBNjTZVeQ.GBvMCFsWJdqmJV U98XPs_GWfbhSIy5hBcP2Z8jY6JhJumyRFD7b6ZLm4v5tM0LHYLAzizGzzCMj5zXfgWzkhLPfO2c 5EVjNFXS8RYHPbuhcqugKfD1iPon_DaZr1a.FxG1jIftmUXEMPfmPHZ_PFCfB2DvVV4TfOXNXY_a yIj.46R5vsOdF1g0qenjTUdpMLtJAemMU6QNKTys9pyfa985oMmmIeXgVSL5pqmewZ3wTAAHSBSs PDYh6HKM42KeZcyKdWF1o5u8ujKVeitZLG0viZGZmsi45RquxHnpDmqwf6XigR6.veLpk6g6x2OZ co.kf81YNTLlctw5gl5O_lbU973xrf4RduQiOvnKyfSmktl6M_ecz9Lm5y.g5MXcGbRqmOca5948 NfjKOofJVjKcAitRE_Z9C3M4hT5oXK7FmRegMUwHaRttEa3xajlzEuruk340YD6QbUAhG2BOgZRO FFpY3A18OrvtYDWS56taEwyTi.47gD1JHMunK.rujNiA0SxInyUIl8Uox8WANlv_EvqMpUcAioRH gdw3q.IHjV4x.dq2PEX45OvRamRZnYO2LwvpGj1J7b0ayXdBfbO4cgWn9ERYdaFaeqKhYnCoGQCS s42rUxN7WIDJmpQpFaAjv2VnY4uPVX8K6LTYwWmPY6yc5Bm0DekXN7IE3PA_mb8Zhz5yquHMJAsa W03KaqjxTyc23XnY1P7te0gqot3CMQiruySbRaCmdxp71tCnCjKj67t_fHmuSBkywhk0z.Lmfso7 XRn1ThbH09XPVVPI4nkJBFWU9.9MO8Hhbr4UeeiUyhQvowkCTZiSmbd26BWERrdWWP0IFbV_b7yh Eb4qKACZ48rTUzb76HoHkqe044EFhDdMDkHYpAKOmcGdZ6jbUSJPm3.M45g8SIK1YE22h.r36wmC XTdPnbIV2ibMnNIX3E2u6.Z1v27Hy6dnd4EPLkoz4.YW0anIi3T_ZwDbTB84neV3U291mgeie3g0 W1Gozsj48dAzlkHycRUlfRdu0KdQbQpRXyK7oShQ2cl4eVK8JmKaRJn7iGC2APs4Hf5E.8petYDH 3k2CdBpqQ7IZN9Sxgrh9W_fwp23pGoJwduzfsabX1WYgxh1R3v1k5o0MqCCOwJBJb3tOirzD6rTv eXOEmprND1zhp5fvH78Ad6f4BGpYUZHoWydUYRHCjq6.yJMTf14Q3662AnjdLb2vOt1SXnvU9yu9 N5o6uFDaTZtjbNwnX50o6Soa75wGKG8FeQ7E3bQ8aKDsvul16izXEkaw6YM8W1bfYP3HGQQJ0oDg BdJk_NMfl1jonLHfNnC0Ozw9pIstZqJjOjK1gElXvc9GQm2hvzVmNB1yGAdulbGpedxRiaCFxXFg TTj86jHjFSrk3Vq9YoBZSk0Og7JUI5MSbXiXxWr0vBwxODn8bASDkGIMr4JVOaNCsGXom1BEXj53 0wEkgSLrIHIV1dCR5vRfIOZZVnxxelhQek1xV.ByV6jvT1xyfb_yNvZN0mIN27PSWd5lUM7m.VcR dOzor5SwdEaabqY2TfioyMB3CgRCefxs_7Jl62Ac77hpmu1Dcp9U8BPe8dwX2OcMWHmi0ezfaqmw 1tQ4YK1RjnTrDws1qiHr7bPfO3ubSFd8qQROIZ.Ro5jpBgoFu4Jq9Bvm.LPi7v0jak0v0WvpLpyc 6uPbJqSClZW4z63Zdt43OkWQGW9_7_2g4RMDXIVwJGJrABe3CJVSjgVqRA29iBgaHPzrIs_1Q04r PbPNzyVKlEd5jwmAHG6nu8_wZT1jhsGhIg2v7a4VkwPbk94NpInOyQz78Ko.B1UwwNilxURUEBnQ xaLkurAQ5.zvyLlwpSpmmLQetA9jiBX.9Dp.u3_YyIPwBOvMebSNJoBpQJD08X1IdpGXHwV9fOou gRe_elohH9r.0aQ6Iia3uQhdxfUhNRJZrUoPkv8RbvltOJ12kbIlhUMdo_adGpEjMdJ47Yw.dXUd iiShzLk.mc6mV0AR_uhsiKBNYl3m8QgBV_8YGqyKVUUTBCdmgKT5cdG5cDaTE_DlrchRjx1iTqtt XBFT7B3k8YmIufB_KJfZLnM7G9Yb852hOgKZIN_gGZ6fEwLPVvxh4zLZyPCD9Xj2Ae_8nO1fcuki PEMirbP4nmgR_B44920pkurvwwig2dOww5t1pqnwdhNJcC1TjXkrHDKx_kbBTrYeTJZwUVpcxBSk eldopKyi1KzT2BwFbQcqVwSEy9a_IRv7GLXrsUvthOeYjDlKc.mOgcZrQk2zY0yVZ5N3qwn0H.K2 w5T1Thn5x X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Sat, 25 Feb 2023 09:39:39 +0000 Received: by hermes--production-sg3-9fc5746c8-7wpmf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2fbedf61b1cff97a3f1766fd44301b4e; Sat, 25 Feb 2023 09:37:36 +0000 (UTC) From: Po Lu To: Eli Zaretskii Subject: Re: bug#61779: 30.0.50; excessive redisplay when the mini window is active In-Reply-To: <83ilfqkv1o.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 25 Feb 2023 10:29:07 +0200") References: <878rgm46d6.fsf.ref@yahoo.com> <878rgm46d6.fsf@yahoo.com> <83ilfqkv1o.fsf@gnu.org> Date: Sat, 25 Feb 2023 17:37:14 +0800 Message-ID: <87v8jq2iid.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21221 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 2927 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61779 Cc: 61779@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> Date: Sat, 25 Feb 2023 14:16:37 +0800 >> From: Po Lu via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> For some reason redisplay_internal will always update the mini window >> even if its buffer contents have not changed. I guess there is probably >> a missing optimization wrt to updating the echo area contents, and >> window_outdated does not take the echo area message into account: >> >> && (CHARPOS (tlbufpos) == ZV >> || FETCH_BYTE (BYTEPOS (tlbufpos)) == '\n')) >> /* Former continuation line has disappeared by becoming empty. */ >> goto cancel; >> else if (window_outdated (w) || MINI_WINDOW_P (w)) <============== >> { >> /* We have to handle the case of continuation around a >> wide-column character (see the comment in indent.c around >> line 1340). >> >> I am not sure that is why, however, so I can't just change that. >> Anyway, update_window_line does not draw anything since the contents of >> the glyph row do not change after redisplay, so that part is fine. The >> problem is that the redisplay will lead to update_window being called, >> and gui_update_window_end will always call display_and_set_cursor >> afterwards to display the cursor, which is not okay, as it generates a >> lot of X protocol traffic when redisplay is called and redisplays the >> mini-window. Now add to that a process generating a lot of output, and >> by doing so, calls to redisplay_preserve_echo_area, and you have an >> absurd number of X requests, enough to saturate any reasonable network >> connection. >> >> Here is a patch to resolve the problem by not redrawing the cursor when >> Emacs knows it is already there. I've not seen any ill effects so far, >> but the comment originally there seems to know better, so what are the >> cases where ``phys_cursor_on_p is 1 but the cursor has been erased''? > > This is okay for master, thanks. The comment that was there still makes me uncomfortable, so: > Btw, the code which tests MINI_WINDOW_P here: > >> && (CHARPOS (tlbufpos) == ZV >> || FETCH_BYTE (BYTEPOS (tlbufpos)) == '\n')) >> /* Former continuation line has disappeared by becoming empty. */ >> goto cancel; >> else if (window_outdated (w) || MINI_WINDOW_P (w)) <============== >> { >> /* We have to handle the case of continuation around a >> wide-column character (see the comment in indent.c around >> line 1340). > > is very old, dating back to the initial revision of xdisp.c before the > Emacs 21 display engine changes, so maybe we should try removing that > instead (assuming that it is related to the more general change > regarding the cursor you want to install). I guess that's the better idea, since it's the only reasonable way I found to make update_window be called extremely often without any changes actually happening.