From unknown Sun Aug 17 09:08:43 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#2530 <2530@debbugs.gnu.org> To: bug#2530 <2530@debbugs.gnu.org> Subject: Status: 23/NS: redraws according to mouse-face are slow Reply-To: bug#2530 <2530@debbugs.gnu.org> Date: Sun, 17 Aug 2025 16:08:43 +0000 retitle 2530 23/NS: redraws according to mouse-face are slow reassign 2530 emacs submitter 2530 David Reitter severity 2530 normal tag 2530 unreproducible thanks From david.reitter@gmail.com Sun Mar 1 14:34:33 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 1 Mar 2009 22:34:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n21MYUHJ029818 for ; Sun, 1 Mar 2009 14:34:31 -0800 Received: from mx10.gnu.org ([199.232.76.166]:46359) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LduCd-0006JL-Mo for emacs-pretest-bug@gnu.org; Sun, 01 Mar 2009 17:32:08 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LduEu-0003Yx-Gz for emacs-pretest-bug@gnu.org; Sun, 01 Mar 2009 17:34:29 -0500 Received: from an-out-0708.google.com ([209.85.132.243]:55272) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LduEu-0003Yt-6s for emacs-pretest-bug@gnu.org; Sun, 01 Mar 2009 17:34:28 -0500 Received: by an-out-0708.google.com with SMTP id b6so1258977ana.21 for ; Sun, 01 Mar 2009 14:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:mime-version:subject:date:x-mailer; bh=+cweOBbHikjNslLze5sB3usSV20rAGGdOekAzICSGTc=; b=E8yWsezt3yG904451agbaw+Tl3O1zg/A70Ng3G1VjWJs9vDUjnmfeTEUJ5/F7h/OGo zOG9MJ1rs2FM/YRMkZaLwKAoel4be1I+hA6PoiQ7X6iqN6kymLIahvcZnzbDCLOuAXD7 GQvXz8NGh9aY9ErWN9QqvKi+R98XHwT7Smh9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:mime-version:subject:date:x-mailer; b=qhapXz95OI/7GWDE5tEkLC90Q5vo96LNj3ngHdoTYZvpurOIbF9hE8l73DMZYLtLLi mvcgiNgmFD9zivLbhW1HzLFf2W8HE+ASH7XokUf+DYTWcBcsLkrmpvNZv8eJBnDpecH6 S7N5NmUv1R6Jk5GHGaNm8NFluNe0qZeOgihK0= Received: by 10.101.68.19 with SMTP id v19mr4300429ank.58.1235946867614; Sun, 01 Mar 2009 14:34:27 -0800 (PST) Received: from scarlett.local (pool-71-162-28-49.pitbpa.east.verizon.net [71.162.28.49]) by mx.google.com with ESMTPS id b7sm8862810ana.19.2009.03.01.14.34.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 01 Mar 2009 14:34:26 -0800 (PST) Message-Id: <05348209-AF46-4D84-B77B-42CF722C29DB@gmail.com> From: David Reitter To: emacs-pretest-bug@gnu.org Content-Type: multipart/signed; boundary=Apple-Mail-8--58373203; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Subject: 23/NS: redraws according to mouse-face are slow Date: Sun, 1 Mar 2009 17:34:24 -0500 X-Mailer: Apple Mail (2.930.3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) --Apple-Mail-8--58373203 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I find that the redisplay of overlays that happens when the mouse is moved into an overlay with a mouse-face property are much slower in Emacs 23 (NS, under Cocoa/OS X). It is pretty much a nasty animation - every layer is redrawn from left to right, it seems, and every step is visible. It seems that background is drawn first, and then the text over it. The overlays I am working with are in the header-line; I'm using (an adapted version of) tabbar.el for this. The resulting package is a not stand-alone and I'd have a hard time turning it into a small test case; before I work on this, I'd rather ask here if this problem is a known one. I have experimented with calls to NSDisableScreenUpdates () in ns_update_begin, ns_update_window_begin and ns_focus, but that didn't help at all. --Apple-Mail-8--58373203 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFxDCCAn0w ggHmoAMCAQICED6shx13jEDrq0eL8FRq5ykwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwOTAyMDgwMVoXDTA5MTIwOTAyMDgw MVowYjEQMA4GA1UEBBMHUmVpdHRlcjEOMAwGA1UEKhMFRGF2aWQxFjAUBgNVBAMTDURhdmlkIFJl aXR0ZXIxJjAkBgkqhkiG9w0BCQEWF2RhdmlkLnJlaXR0ZXJAZ21haWwuY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDOdo6kAwlkBxUb8dj4saMbYg4SVng8CUePFn3cjjWrakBTbUVa4Z0n wlUxr7AitEeKhBy5nGhu96+jKUPrCwYNRCZ0l2ovvuGq4z1m1nZ5/c8WvFlVhieuxXMUfmb/O7D3 IojoX6iS8n5MNNU2IWNNT/AD3vOl6DKgOtOw4J9y+QIDAQABozQwMjAiBgNVHREEGzAZgRdkYXZp ZC5yZWl0dGVyQGdtYWlsLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAIjI8yEW wkiEfA9PMgpjnD6KyCXT0iZjHhW2PkR53yZZLUoTboHnKgsFwYp/gzzIL8J5cvZaRUyMUzXDufPP dRmxxCs2jXXLDD/8bvdvOuMzqgYoFA73fAfsC8S6qUL1PayZ90J8CZHNhDwqWqOA56T+DdKUegJT sqoHKh6OnypTMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJz b25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVow YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU 5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFs RnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2 YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5 jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAo8wggKLAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA+rIcdd4xA66tH i/BUaucpMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA5MDMwMTIyMzQyNFowIwYJKoZIhvcNAQkEMRYEFNArCOLfc2l3i2CKTwbWG2iyGCjd MIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQPqyHHXeMQOurR4vwVGrnKTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQPqyHHXeMQOurR4vwVGrnKTANBgkqhkiG9w0B AQEFAASBgBYCRegDMWzk9bnb0dD7HT/G1pPSMEmdPTjzQdhxk9vL5S5CU86fhs4poYdVajg0ihl2 sB/reE4MRRJBSoPtPqgDfHXBTBfRsJLaWJ7hq7Q5LkAn5fquQ87RFlDD9HmtOF6yQK0LPdToWbap iAhaDZ/wtG5ZPN+6f/qrNmKZYzv8AAAAAAAA --Apple-Mail-8--58373203-- From rgm@gnu.org Mon Mar 2 00:10:37 2009 Received: (at control) by emacsbugs.donarmstrong.com; 2 Mar 2009 08:10:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-5.0 required=4.0 tests=VALID_BTS_CONTROL, X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n228AYRx014029 for ; Mon, 2 Mar 2009 00:10:35 -0800 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1Le3C5-0001cJ-Rr; Mon, 02 Mar 2009 03:08:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18859.37865.767989.757577@fencepost.gnu.org> Date: Mon, 2 Mar 2009 03:08:09 -0500 From: Glenn Morris To: control Subject: control message X-Debbugs-No-Ack: yes reassign 2525 emacs,ns reassign 2526 emacs,ns severity 2527 minor reassign 2530 emacs,ns reassign 2531 emacs,ns reassign 2532 emacs,ns reassign 2534 emacs,ns reassign 2535 spam From adrian.b.robert@gmail.com Wed Mar 4 13:29:22 2009 Received: (at 2530) by emacsbugs.donarmstrong.com; 4 Mar 2009 21:29:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n24LTJqW020071 for <2530@emacsbugs.donarmstrong.com>; Wed, 4 Mar 2009 13:29:20 -0800 Received: by ewy24 with SMTP id 24so3034995ewy.1 for <2530@emacsbugs.donarmstrong.com>; Wed, 04 Mar 2009 13:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:mime-version:content-type :message-id:cc:content-transfer-encoding:from:subject:date:to :x-mailer; bh=edXLk/Gl0lDIZIGcCTIsWk2lQwxkdagXjy1MXtHAUjM=; b=CWpgNPq6cxQdyeMt/GYOXCsYBsABW/7pJZiuEdT2yeiut3zhO8r0NnMiDzNCf10uCz Dv54JNDcLf7AaX8zT2ytN712gX48aNSQHGhFgRTUjkZmPbDGUiB/jsyMg3jJST7rO1y1 LwSEadzhA5Bby1tSjhWrg8hck3D5bOArPFZwY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:content-type:message-id:cc:content-transfer-encoding :from:subject:date:to:x-mailer; b=XkFVfPIbBzW3uv0dCnYM61rWSwIpbS2n0bIgn/dg6uugSfBcX6QRCVTMPZOyRmHJce 2VC0thK0hp8WeqItNQ19FdB7b1AuTLTDL6n/OeBC432XmZnHc9H7utPpXcTWukw4xann Di+YBrRt/2zOOsVNZaehc2ZY8WrhWpOgBmVHM= Received: by 10.216.52.203 with SMTP id e53mr142633wec.209.1236202152821; Wed, 04 Mar 2009 13:29:12 -0800 (PST) Received: from ?88.194.239.235? (gprs-prointernet-ffefc200-235.dhcp.inet.fi [88.194.239.235]) by mx.google.com with ESMTPS id i3sm15256518nfh.73.2009.03.04.13.29.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Mar 2009 13:29:11 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: David Reitter Content-Transfer-Encoding: 7bit From: Adrian Robert Subject: Re: 23/NS: redraws according to mouse-face are slow Date: Wed, 4 Mar 2009 23:29:48 +0200 To: 2530@debbugs.gnu.org X-Mailer: Apple Mail (2.753.1) > I find that the redisplay of overlays that happens when the mouse is > moved into an overlay with a mouse-face property are much slower in > Emacs 23 (NS, under Cocoa/OS X). It is pretty much a nasty animation > - every layer is redrawn from left to right, it seems, and every step > is visible. It seems that background is drawn first, and then the > text over it. Yes, this has been an issue for years from Emacs on Aqua on and it completely baffles me. The NS code for handling mouse face is identical to other platforms as far as I can tell, so I don't know why the issue occurs only here. And the animation is far slower than any code on the NS side could be taking. It must be a bug somewhere on the core display side that is exposed because (guessing here) the event loop under NS is done slightly differently. From david.reitter@gmail.com Mon Apr 20 11:01:25 2009 Received: (at 2530) by emacsbugs.donarmstrong.com; 20 Apr 2009 18:01:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3KI1LYV014184 for <2530@emacsbugs.donarmstrong.com>; Mon, 20 Apr 2009 11:01:23 -0700 Received: by yx-out-2324.google.com with SMTP id 8so764957yxg.31 for <2530@emacsbugs.donarmstrong.com>; Mon, 20 Apr 2009 11:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=S6hP1PAfvg+rrcqMCenCULy2fR+miSf3MfvlE0mOIY8=; b=hJRssb8+xVxnxAgbR2yx2s4mj3Yjhf+maEs0dEmOYWT6+rdXABL/nKJ9z/MpXRxojW 8mY9KaE0Y0s9mbc9EtrZNnAVkLTGdZSYHZRCm1kY1z1h1UUs8L1lIDeIaPQbhaLvlqkZ tnfxiZrA7VTdxx13vuYAKADXMjzICUxTGSOeg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:mime-version:subject :date:references:x-mailer; b=fuPhCmEOCqxqZ+n2L8tbtHULrQTvW31jx/g5ti0cwKGdVSje1PaRpwBKlQqlJZvGJH R1qrW4aW1tjbgQfWO7zEMNxNMCBrkMdBa6UAdkXgK4DCkOku+3CsKUo1ycrDvS8hI5Gq NGlIHYv5V1XwzpPVD5Uldcf/SnMzYWHxjotrU= Received: by 10.101.70.14 with SMTP id x14mr3508722ank.85.1240250481405; Mon, 20 Apr 2009 11:01:21 -0700 (PDT) Received: from SCARLETT.PSY.CMU.EDU (SCARLETT.PSY.CMU.EDU [128.2.249.106]) by mx.google.com with ESMTPS id b37sm8802498ana.12.2009.04.20.11.01.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Apr 2009 11:01:19 -0700 (PDT) Cc: 2530@debbugs.gnu.org, Emacs-Devel devel Message-Id: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> From: David Reitter To: Adrian Robert In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-20--49726979; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: 23/NS: redraws according to mouse-face are slow Date: Mon, 20 Apr 2009 14:01:17 -0400 References: X-Mailer: Apple Mail (2.930.3) --Apple-Mail-20--49726979 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 4, 2009, at 4:29 PM, Adrian Robert wrote: >> I find that the redisplay of overlays that happens when the mouse is >> moved into an overlay with a mouse-face property are much slower in >> Emacs 23 (NS, under Cocoa/OS X). It is pretty much a nasty animation >> - every layer is redrawn from left to right, it seems, and every step >> is visible. It seems that background is drawn first, and then the >> text over it. > > Yes, this has been an issue for years from Emacs on Aqua on and it > completely baffles me. The NS code for handling mouse face is > identical to other platforms as far as I can tell, so I don't know > why the issue occurs only here. And the animation is far slower > than any code on the NS side could be taking. It must be a bug > somewhere on the core display side that is exposed because (guessing > here) the event loop under NS is done slightly differently. Does anyone have an idea how to fix issue 2530? I think this slowness is quite painful. In my case, it is the tabbar.el variant that I'm using that causes this - I'm using several overlays (for a tab-close button, for instance) that get redrawn one by one. I would imagine that this will annoy users in other use cases as well. --Apple-Mail-20--49726979 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFxDCCAn0w ggHmoAMCAQICED6shx13jEDrq0eL8FRq5ykwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwOTAyMDgwMVoXDTA5MTIwOTAyMDgw MVowYjEQMA4GA1UEBBMHUmVpdHRlcjEOMAwGA1UEKhMFRGF2aWQxFjAUBgNVBAMTDURhdmlkIFJl aXR0ZXIxJjAkBgkqhkiG9w0BCQEWF2RhdmlkLnJlaXR0ZXJAZ21haWwuY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDOdo6kAwlkBxUb8dj4saMbYg4SVng8CUePFn3cjjWrakBTbUVa4Z0n wlUxr7AitEeKhBy5nGhu96+jKUPrCwYNRCZ0l2ovvuGq4z1m1nZ5/c8WvFlVhieuxXMUfmb/O7D3 IojoX6iS8n5MNNU2IWNNT/AD3vOl6DKgOtOw4J9y+QIDAQABozQwMjAiBgNVHREEGzAZgRdkYXZp ZC5yZWl0dGVyQGdtYWlsLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAIjI8yEW wkiEfA9PMgpjnD6KyCXT0iZjHhW2PkR53yZZLUoTboHnKgsFwYp/gzzIL8J5cvZaRUyMUzXDufPP dRmxxCs2jXXLDD/8bvdvOuMzqgYoFA73fAfsC8S6qUL1PayZ90J8CZHNhDwqWqOA56T+DdKUegJT sqoHKh6OnypTMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJz b25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVow YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU 5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFs RnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2 YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5 jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAo8wggKLAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA+rIcdd4xA66tH i/BUaucpMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA5MDQyMDE4MDExOFowIwYJKoZIhvcNAQkEMRYEFHzqz5C9u2oH/jweLq4i5GMUMtrR MIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQPqyHHXeMQOurR4vwVGrnKTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQPqyHHXeMQOurR4vwVGrnKTANBgkqhkiG9w0B AQEFAASBgLTU5Ik3XHOpl+RPnuWk7ExYXxuT+SlzDv2usFUr8QUFDaXRXMO698VjlY1ljgwhw6Ah Vm8uU7HgC3mfTuM6QIZoP8YMHw2wh9QDUGA8arqD7zuo522T+P6mNtAU7Hz2ZSOkP6v0n/mZrNIm nwVWOtv7+uPEWzSq4fuZko6ld3nlAAAAAAAA --Apple-Mail-20--49726979-- From adrian.b.robert@gmail.com Thu Apr 23 20:26:00 2009 Received: (at 2530) by emacsbugs.donarmstrong.com; 24 Apr 2009 03:26:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3O3Pvd5025316 for <2530@emacsbugs.donarmstrong.com>; Thu, 23 Apr 2009 20:25:58 -0700 Received: by yx-out-2324.google.com with SMTP id 8so549707yxg.31 for <2530@emacsbugs.donarmstrong.com>; Thu, 23 Apr 2009 20:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:in-reply-to:references :mime-version:content-type:message-id:cc:content-transfer-encoding :from:subject:date:to:x-mailer; bh=5Ar4ORVxm/3jU4OItVBqIDYk+Lj+dHsG4oYZdLr7nws=; b=k9qCT/4UrFqocedGivowDuQacYZXpBVAi6x2Guc6Tn3c0sH4tjd6pcHXKGA7ceyIch eppCJQWClOqcPs6MiYXWbQkpFwVT4JhqYPvbrJPpHjQwmYOlppwjCoIvAU19976yv/eo 8/YV2pVqrh1AW2enIbkiPku3EV4MLghSCtl5I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=in-reply-to:references:mime-version:content-type:message-id:cc :content-transfer-encoding:from:subject:date:to:x-mailer; b=q3HDbQRjowQokv0Nv69qaT6qmSrhmZSp8YzJWXJ/Y4P8wmsEWR2YwQqH+54Yni5p5i /9GWET7c1wEfTTCsQpskpOVze9m4m0drnItllfPvIeK6KKK/siln0HfOQtJBvcQDuMFv PyieUxas35pFP2LePJwNVbJgnu3aTQEep607w= Received: by 10.90.89.8 with SMTP id m8mr2094578agb.23.1240543556688; Thu, 23 Apr 2009 20:25:56 -0700 (PDT) Received: from ?192.168.108.203? (gprs-prx.spicenepal.com [116.68.208.84]) by mx.google.com with ESMTPS id 21sm1482842agd.51.2009.04.23.20.25.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 23 Apr 2009 20:25:55 -0700 (PDT) In-Reply-To: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> References: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com> Cc: 2530@debbugs.gnu.org, Emacs-Devel devel Content-Transfer-Encoding: 7bit From: Adrian Robert Subject: Re: 23/NS: redraws according to mouse-face are slow Date: Fri, 24 Apr 2009 09:12:46 +0545 To: David Reitter X-Mailer: Apple Mail (2.753.1) On Apr 20, 2009, at 11:46 PM, David Reitter wrote: > On Mar 4, 2009, at 4:29 PM, Adrian Robert wrote: > >>> I find that the redisplay of overlays that happens when the mouse is >>> moved into an overlay with a mouse-face property are much slower in >>> Emacs 23 (NS, under Cocoa/OS X). It is pretty much a nasty >>> animation >>> - every layer is redrawn from left to right, it seems, and every >>> step >>> is visible. It seems that background is drawn first, and then the >>> text over it. >> >> Yes, this has been an issue for years from Emacs on Aqua on and it >> completely baffles me. The NS code for handling mouse face is >> identical to other platforms as far as I can tell, so I don't know >> why the issue occurs only here. And the animation is far slower >> than any code on the NS side could be taking. It must be a bug >> somewhere on the core display side that is exposed because >> (guessing here) the event loop under NS is done slightly differently. > > Does anyone have an idea how to fix issue 2530? I think this > slowness is quite painful. In my case, it is the tabbar.el variant > that I'm using that causes this - I'm using several overlays (for a > tab-close button, for instance) that get redrawn one by one. I > would imagine that this will annoy users in other use cases as well. Or to ask it another way, is there any reason anyone can think of that redisplay would force calls through the x_draw_glyph_string pathway once for every character when overlays are present? From david.reitter@gmail.com Mon May 4 14:58:48 2009 Received: (at 2530) by emacsbugs.donarmstrong.com; 4 May 2009 21:58:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-qy0-f110.google.com (mail-qy0-f110.google.com [209.85.221.110]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n44LwgPC021257 for <2530@emacsbugs.donarmstrong.com>; Mon, 4 May 2009 14:58:44 -0700 Received: by qyk8 with SMTP id 8so7305477qyk.19 for <2530@emacsbugs.donarmstrong.com>; Mon, 04 May 2009 14:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=HAguLaAc+RPtuZV38lyawZ9+y8itHIQa1m6nKilROok=; b=upC+3saykPCGSgY8256JH03PaJ3xq+BF16Z5Wf9lPHAi6jtq7U0vizUnEpjYnwC0Xc kigAtz1ph3r52g7xJ286SHk+ha96dcQ40o77SXe5g74OIiIF2RACcSsPZPfC9GZOde// etNvEAk7Y1UihgaVePdPNcmKAizdevmmYKLbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:mime-version:subject :date:references:x-mailer; b=hQjYkmB77hI6VaxzftYeORHJf+I5xfb4kQj5vHti3c7MjKWlm8HY9Sr9mFk7xU3Rek 7OXhaIywD3KEB4EVFPn0fqHYNNeWbjDC8Iw0EVO7EE45ZLmnQ9ibIebHUiKiRn5AsPUj 1vI1wWw7poM3ImfNaEaM6ReJudp2CbN0TjHD0= Received: by 10.224.54.75 with SMTP id p11mr6436301qag.207.1241474317156; Mon, 04 May 2009 14:58:37 -0700 (PDT) Received: from scarlett.local (pool-71-162-19-47.pitbpa.east.verizon.net [71.162.19.47]) by mx.google.com with ESMTPS id 34sm1215007yxl.35.2009.05.04.14.58.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 May 2009 14:58:36 -0700 (PDT) Cc: Emacs-Devel devel , 2530@debbugs.gnu.org Message-Id: <5C2B30D1-59E7-40D1-866B-3EA70CC0B568@gmail.com> From: David Reitter To: Ian Eure In-Reply-To: <005B7935-3DF1-4827-A507-6F83D8615626@digg.com> Content-Type: multipart/signed; boundary=Apple-Mail-42--973375825; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: NextStep port is in bad shape Date: Mon, 4 May 2009 17:58:32 -0400 References: <005B7935-3DF1-4827-A507-6F83D8615626@digg.com> X-Mailer: Apple Mail (2.930.3) --Apple-Mail-42--973375825 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Ian, On May 4, 2009, at 4:06 PM, Ian Eure wrote: > The main issue is performance. It's _really_ slow. In particular, > using Flyspell makes it really horrible to use (#2056). There also > seem to be problems with slow redrawing. If you highlight a URL in > ERC with the mouse, then move point across it, you can see it lag > and redraw the entire highlighted region. Drawing a highlight over a > multi-line area is so slow that you can watch it draw. > > In general, it just doesn't feel like it's ready for a stable > release. Are these issues known and is someone working on them? Yes, the issue has been known for a long time. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=2530 To reproduce: Emacs -Q type: load-history C-j move mouse cursor over output. The last message about this come from Adrian Roberts, on Apr 23: >> On Apr 20, 2009, at 11:46 PM, David Reitter wrote: > >> Does anyone have an idea how to fix issue 2530? I think this >> slowness is quite painful. In my case, it is the tabbar.el variant >> that I'm using that causes this - I'm using several overlays (for a >> tab-close button, for instance) that get redrawn one by one. I >> would imagine that this will annoy users in other use cases as well. > > Or to ask it another way, is there any reason anyone can think of > that redisplay would force calls through the x_draw_glyph_string > pathway once for every character when overlays are present? --Apple-Mail-42--973375825 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFxDCCAn0w ggHmoAMCAQICED6shx13jEDrq0eL8FRq5ykwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwOTAyMDgwMVoXDTA5MTIwOTAyMDgw MVowYjEQMA4GA1UEBBMHUmVpdHRlcjEOMAwGA1UEKhMFRGF2aWQxFjAUBgNVBAMTDURhdmlkIFJl aXR0ZXIxJjAkBgkqhkiG9w0BCQEWF2RhdmlkLnJlaXR0ZXJAZ21haWwuY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDOdo6kAwlkBxUb8dj4saMbYg4SVng8CUePFn3cjjWrakBTbUVa4Z0n wlUxr7AitEeKhBy5nGhu96+jKUPrCwYNRCZ0l2ovvuGq4z1m1nZ5/c8WvFlVhieuxXMUfmb/O7D3 IojoX6iS8n5MNNU2IWNNT/AD3vOl6DKgOtOw4J9y+QIDAQABozQwMjAiBgNVHREEGzAZgRdkYXZp ZC5yZWl0dGVyQGdtYWlsLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAIjI8yEW wkiEfA9PMgpjnD6KyCXT0iZjHhW2PkR53yZZLUoTboHnKgsFwYp/gzzIL8J5cvZaRUyMUzXDufPP dRmxxCs2jXXLDD/8bvdvOuMzqgYoFA73fAfsC8S6qUL1PayZ90J8CZHNhDwqWqOA56T+DdKUegJT sqoHKh6OnypTMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJz b25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVow YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU 5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFs RnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2 YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5 jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAo8wggKLAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA+rIcdd4xA66tH i/BUaucpMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA5MDUwNDIxNTgzM1owIwYJKoZIhvcNAQkEMRYEFCZXARBA+YvBRgo7nsAG/JaQDRrg MIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQPqyHHXeMQOurR4vwVGrnKTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQPqyHHXeMQOurR4vwVGrnKTANBgkqhkiG9w0B AQEFAASBgC/p05Ir8AkIe+2rPIXyzYkUIr6QCt6eEEoXWfqmJvd9vuPhdgukLyeCAhNwIr2DRsA1 3ZDuBTEOG5Twx5jY+P2vrNocxXGWdC20lQSq0Uz6fEDT/s7W2qF2IjOqKGb2+qHuvrd4dMa+FLVR paqRuQ7SPuUqlYTh5gYxD89bpvc2AAAAAAAA --Apple-Mail-42--973375825-- From david.reitter@gmail.com Mon May 4 15:55:24 2009 Received: (at 2530) by emacsbugs.donarmstrong.com; 4 May 2009 22:55:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.1 required=4.0 tests=FOURLA,IMPRONONCABLE_2, MURPHY_DRUGS_REL8 autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-qy0-f110.google.com (mail-qy0-f110.google.com [209.85.221.110]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n44MtKgi005437 for <2530@emacsbugs.donarmstrong.com>; Mon, 4 May 2009 15:55:21 -0700 Received: by qyk8 with SMTP id 8so7357355qyk.19 for <2530@emacsbugs.donarmstrong.com>; Mon, 04 May 2009 15:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=7ltvVMMCsrxG6tbZlXcXEysvDMkEE0y6Je2m77LViIw=; b=whqtIkuX/UAdIzQCLHlMh2DrzeJCdLPMG7yvKC+0NZRjwMBvy56w5ZfMRjhcWvs5bZ BYlPLpYtqZg8b8KOxb3oMBIB5UH2t8X501ikZZhLL+OCu7Rn9o9BGp4YG+gFHNQNE34L VjxM3QKXVLYJnMx6uydFNKtbP+5esB4osq8F0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:mime-version:subject :date:references:x-mailer; b=PoHC7DA6mO68BE8+HkmtfdgC92U4iUtLmooqX3bO0a5CR/TmUOQoQZD9K/Ter76XH1 LvPkHOBrG5WLF5wNZqzRsji1SpDBxBlpVRQNZ5h1INo0/ZkugIp+Ygv93ZSm2r+kVJ7l 0vaDcde3I9e37LzkOeRHtoD3+iy+51t596JQI= Received: by 10.220.44.206 with SMTP id b14mr10231780vcf.55.1241477715025; Mon, 04 May 2009 15:55:15 -0700 (PDT) Received: from scarlett.local (pool-71-162-19-47.pitbpa.east.verizon.net [71.162.19.47]) by mx.google.com with ESMTPS id 8sm1138522ywg.3.2009.05.04.15.55.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 May 2009 15:55:13 -0700 (PDT) Cc: 2530@debbugs.gnu.org, Emacs-Devel devel , Ian Eure Message-Id: From: David Reitter To: Adrian Robert In-Reply-To: <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com> Content-Type: multipart/signed; boundary=Apple-Mail-43--969978604; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: 23/NS: redraws according to mouse-face are slow Date: Mon, 4 May 2009 18:55:09 -0400 References: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com> X-Mailer: Apple Mail (2.930.3) --Apple-Mail-43--969978604 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Apr 23, 2009, at 11:27 PM, Adrian Robert wrote: >> Does anyone have an idea how to fix issue 2530? I think this >> slowness is quite painful. In my case, it is the tabbar.el variant >> that I'm using that causes this - I'm using several overlays (for a >> tab-close button, for instance) that get redrawn one by one. I >> would imagine that this will annoy users in other use cases as well. > > Or to ask it another way, is there any reason anyone can think of > that redisplay would force calls through the x_draw_glyph_string > pathway once for every character when overlays are present? OK, my observation from tracing this is that it doesn't draw every glyph separately, but that it identifies regions of a common face, at best a full row of course. In the case of mouse-face, in the load- history-C-j example, we still have a lot of separate strings because without the mouse-face, there are still a lot of separate regions. The distinction between them may be lost (which is very unfortunate from an UI point of view), but the region identification algorithm (BUILD_GLYPH_STRINGS I suppose) doesn't see that. Now, in NS (or at least in Cocoa), there seem to be screen updates every time we draw a glyph string. If we wrap the code in show_mouse_face in NS[Dis|En]ableScreen, the problem goes away for me (and it's not just delayed). Same for the header-line/overlay issues I reported in #2530. Note that I'm not claiming that the patch below is the right fix...: Moving the mouse a bit causes the whole mouse highlight to flicker. I suspect that it's the same underlying problem. I wonder if we need to wrap more code in NSDisableScreenUpdates. diff --git a/src/xdisp.c b/src/xdisp.c index ac989d3..fc319ca 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -22790,6 +22790,10 @@ show_mouse_face (dpyinfo, draw) struct window *w = XWINDOW (dpyinfo->mouse_face_window); struct frame *f = XFRAME (WINDOW_FRAME (w)); +#ifdef NS_IMPL_COCOA + NSDisableScreenUpdates (); +#endif + if (/* If window is in the process of being destroyed, don't bother to do anything. */ w->current_matrix != NULL @@ -22852,6 +22856,9 @@ show_mouse_face (dpyinfo, draw) UNBLOCK_INPUT; } } +#ifdef NS_IMPL_COCOA + NSEnableScreenUpdates (); +#endif /* Change the mouse cursor. */ if (draw == DRAW_NORMAL_TEXT && !EQ (dpyinfo->mouse_face_window, f- >tool_bar_window)) --Apple-Mail-43--969978604 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFxDCCAn0w ggHmoAMCAQICED6shx13jEDrq0eL8FRq5ykwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwOTAyMDgwMVoXDTA5MTIwOTAyMDgw MVowYjEQMA4GA1UEBBMHUmVpdHRlcjEOMAwGA1UEKhMFRGF2aWQxFjAUBgNVBAMTDURhdmlkIFJl aXR0ZXIxJjAkBgkqhkiG9w0BCQEWF2RhdmlkLnJlaXR0ZXJAZ21haWwuY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDOdo6kAwlkBxUb8dj4saMbYg4SVng8CUePFn3cjjWrakBTbUVa4Z0n wlUxr7AitEeKhBy5nGhu96+jKUPrCwYNRCZ0l2ovvuGq4z1m1nZ5/c8WvFlVhieuxXMUfmb/O7D3 IojoX6iS8n5MNNU2IWNNT/AD3vOl6DKgOtOw4J9y+QIDAQABozQwMjAiBgNVHREEGzAZgRdkYXZp ZC5yZWl0dGVyQGdtYWlsLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAIjI8yEW wkiEfA9PMgpjnD6KyCXT0iZjHhW2PkR53yZZLUoTboHnKgsFwYp/gzzIL8J5cvZaRUyMUzXDufPP dRmxxCs2jXXLDD/8bvdvOuMzqgYoFA73fAfsC8S6qUL1PayZ90J8CZHNhDwqWqOA56T+DdKUegJT sqoHKh6OnypTMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJz b25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVow YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU 5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFs RnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2 YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5 jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAo8wggKLAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA+rIcdd4xA66tH i/BUaucpMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA5MDUwNDIyNTUxMFowIwYJKoZIhvcNAQkEMRYEFEfZISr7qLCyYFSqfxYietx+s3sy MIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQPqyHHXeMQOurR4vwVGrnKTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQPqyHHXeMQOurR4vwVGrnKTANBgkqhkiG9w0B AQEFAASBgBV7yLaEaDhMVnCa+fok69UWklZDH9k04EfPMNV8TXXsZigOr+fAtGRibSX/86DMef84 7ZjYM+jAstBZp+yaRoKIax3Y2Qg4Go02Rq+qrtxxRBzJsD6E1WO1giVlEAM5TAS3d3ZNtij4frUL 7jg0LUSOnYr3bpUcZmMLKbOvOkSMAAAAAAAA --Apple-Mail-43--969978604-- From cyd@stupidchicken.com Mon May 4 18:53:07 2009 Received: (at 2530) by emacsbugs.donarmstrong.com; 5 May 2009 01:53:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n451r2oT022892 for <2530@emacsbugs.donarmstrong.com>; Mon, 4 May 2009 18:53:04 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 2535757E25E; Mon, 4 May 2009 21:53:10 -0400 (EDT) From: Chong Yidong To: David Reitter Cc: Adrian Robert , 2530@debbugs.gnu.org, Ian Eure , Emacs-Devel devel Subject: Re: 23/NS: redraws according to mouse-face are slow References: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com> Date: Mon, 04 May 2009 21:53:10 -0400 In-Reply-To: (David Reitter's message of "Mon, 4 May 2009 18:55:09 -0400") Message-ID: <87d4aowc1l.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Thanks for debugging this. > Now, in NS (or at least in Cocoa), there seem to be screen updates > every time we draw a glyph string. I see. It seems ns_draw_glyph_string is a lot more expensive that x_draw_glyph_string. The show_mouse_face function assumes that the *_draw_glyph_string operation is relatively cheap, which is why it's called inside a loop. My guess is that the problem lies in the calls to ns_focus and ns_unfocus in ns_draw_glyph_string. > If we wrap the code in show_mouse_face in NS[Dis|En]ableScreen, the > problem goes away for me (and it's not just delayed). Same for the > header-line/overlay issues I reported in #2530. If possible, we should minimize the amount of platform-dependent code inside xdisp.c. Could you experiment with putting these calls somewhere in nsterm.m, say surrounding the calls to note_mouse_highlight? Also, could it be ns_update_begin and ns_update_end that you want to call, instead of NSDisableScreen and NSEnableScreen? From david.reitter@gmail.com Mon May 4 20:37:38 2009 Received: (at 2530) by emacsbugs.donarmstrong.com; 5 May 2009 03:37:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.0 required=4.0 tests=IMPRONONCABLE_2 autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-gx0-f206.google.com (mail-gx0-f206.google.com [209.85.217.206]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n453bYu7019879 for <2530@emacsbugs.donarmstrong.com>; Mon, 4 May 2009 20:37:35 -0700 Received: by gxk2 with SMTP id 2so9015735gxk.1 for <2530@emacsbugs.donarmstrong.com>; Mon, 04 May 2009 20:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=yqEkP+pWtIbA/ihw7V4lvWq0+RxNzWpjc78iCRQ2gy0=; b=UC42n1dSO2i5vhC5EcU49R7t3KQQnv46zNAWo2KOzfeuxNBQpAoqo7D1a+ONg17Pux PtMn5cHMcyU6EyKaaJft1J1QfTh6QA8VZmlmyuVCTN/rJkV1/TtiTYhEdV9ti+cMMOzT tV/gzcfQpT3HmGI+DujuNam3u9vKksfTDYkWc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:mime-version:subject :date:references:x-mailer; b=EurXDLsgp81Eni+n4PXFJ26lITAGT61gZpiLWiWExgPcj1fKaGKUam8KOZ/iBwkodE HGe/Ix2eF9QdsUXGmfTF7LQ40UAeG4z7HtGY/S46jXtUk7W4CdbvNJ1vchr9MGaFmqca RE/kpzHIud/nM3goUGmN5raB+0YB5BBxpi/Ks= Received: by 10.90.26.3 with SMTP id 3mr5933986agz.27.1241494648571; Mon, 04 May 2009 20:37:28 -0700 (PDT) Received: from scarlett.local (pool-71-162-19-47.pitbpa.east.verizon.net [71.162.19.47]) by mx.google.com with ESMTPS id 39sm11891562agb.71.2009.05.04.20.37.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 May 2009 20:37:27 -0700 (PDT) Cc: Adrian Robert , 2530@debbugs.gnu.org, Ian Eure , Emacs-Devel devel Message-Id: <2E6E5869-2F70-4AF5-A917-7EA863D6BD42@gmail.com> From: David Reitter To: Chong Yidong In-Reply-To: <87d4aowc1l.fsf@cyd.mit.edu> Content-Type: multipart/signed; boundary=Apple-Mail-48--953045564; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: 23/NS: redraws according to mouse-face are slow Date: Mon, 4 May 2009 23:37:22 -0400 References: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com> <87d4aowc1l.fsf@cyd.mit.edu> X-Mailer: Apple Mail (2.930.3) --Apple-Mail-48--953045564 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 4, 2009, at 9:53 PM, Chong Yidong wrote: > I see. It seems ns_draw_glyph_string is a lot more expensive that > x_draw_glyph_string. The show_mouse_face function assumes that the > *_draw_glyph_string operation is relatively cheap, which is why it's > called inside a loop. > > My guess is that the problem lies in the calls to ns_focus and > ns_unfocus in ns_draw_glyph_string. Right - but we still need them, at least for clipping. That said, because of the clipping, calls to ns_focus may be more expensive than desirable. We have multiple calls to ns_draw_glyph_string, often more than one for each row, but we only need one clipping for the whole frame. So, ideally we'd call ns_focus outside the loops that call ns_draw_glyph_string, but the architecture won't allow that. >> If we wrap the code in show_mouse_face in NS[Dis|En]ableScreen, the >> problem goes away for me (and it's not just delayed). Same for the >> header-line/overlay issues I reported in #2530. > > If possible, we should minimize the amount of platform-dependent code > inside xdisp.c. Could you experiment with putting these calls > somewhere > in nsterm.m, say surrounding the calls to note_mouse_highlight? > > Also, could it be ns_update_begin and ns_update_end that you want to > call, instead of NSDisableScreen and NSEnableScreen? Yes, sure, this variant works well, and it takes care of the ugly flicker as well. (However, when moving the mouse over a piece of text with (common) mouse-face property, we shouldn't need to redraw in the first place, and that should be addressed at some point, perhaps after 23.1.) http://github.com/davidswelt/aquamacs-emacs/commit/9e98aaff17dd24ffa45743163df553938815498f There are further places where we need it, e.g. when scrolling. Also, scrolling with the mouse wheel doesn't always work when the mouse is over a highlighted (mouse-faced) piece of text. Will look into this again. --Apple-Mail-48--953045564 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFxDCCAn0w ggHmoAMCAQICED6shx13jEDrq0eL8FRq5ykwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwOTAyMDgwMVoXDTA5MTIwOTAyMDgw MVowYjEQMA4GA1UEBBMHUmVpdHRlcjEOMAwGA1UEKhMFRGF2aWQxFjAUBgNVBAMTDURhdmlkIFJl aXR0ZXIxJjAkBgkqhkiG9w0BCQEWF2RhdmlkLnJlaXR0ZXJAZ21haWwuY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDOdo6kAwlkBxUb8dj4saMbYg4SVng8CUePFn3cjjWrakBTbUVa4Z0n wlUxr7AitEeKhBy5nGhu96+jKUPrCwYNRCZ0l2ovvuGq4z1m1nZ5/c8WvFlVhieuxXMUfmb/O7D3 IojoX6iS8n5MNNU2IWNNT/AD3vOl6DKgOtOw4J9y+QIDAQABozQwMjAiBgNVHREEGzAZgRdkYXZp ZC5yZWl0dGVyQGdtYWlsLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAIjI8yEW wkiEfA9PMgpjnD6KyCXT0iZjHhW2PkR53yZZLUoTboHnKgsFwYp/gzzIL8J5cvZaRUyMUzXDufPP dRmxxCs2jXXLDD/8bvdvOuMzqgYoFA73fAfsC8S6qUL1PayZ90J8CZHNhDwqWqOA56T+DdKUegJT sqoHKh6OnypTMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJz b25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVow YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU 5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFs RnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2 YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5 jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAo8wggKLAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA+rIcdd4xA66tH i/BUaucpMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA5MDUwNTAzMzcyM1owIwYJKoZIhvcNAQkEMRYEFKSp26NSeHkYmu6+QXLXVBNyYBKa MIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQPqyHHXeMQOurR4vwVGrnKTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQPqyHHXeMQOurR4vwVGrnKTANBgkqhkiG9w0B AQEFAASBgE/5BTniXjTI6X+ZIRwYqRgq1fchoQHMpdS63xiU9xmG6/3vvHZlDwI+oauRDUSLRVg8 KvSgc76+O9FiI+nymZtlIewYpGhcXTS58tO96xsxY1EPAy1Zy88oe9YyyM0dlBz26y39kAZF2nE4 SQvFmDqXwNx8e0QAshgGRkoE2NIjAAAAAAAA --Apple-Mail-48--953045564-- From adrian.b.robert@gmail.com Tue May 5 03:36:47 2009 Received: (at 2530) by emacsbugs.donarmstrong.com; 5 May 2009 10:36:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n45Aahar006649 for <2530@emacsbugs.donarmstrong.com>; Tue, 5 May 2009 03:36:44 -0700 Received: by wa-out-1112.google.com with SMTP id m28so1895241wag.1 for <2530@emacsbugs.donarmstrong.com>; Tue, 05 May 2009 03:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:in-reply-to:references :mime-version:content-type:message-id:cc:content-transfer-encoding :from:subject:date:to:x-mailer; bh=biewUTrKoLvaK1qsodL2M1T8sRg2z7sok2b88jkLMlk=; b=X0mUrPVkExIOAslH/vxgtirVaNhrU5pp7OJK9dCsJEodTApMKiUwS6V4OlTRK85sD2 01h3HJtqicNXD67jgeLV1jDgaKx1yLjWoJu6rHQEFol0Vv368z6zJE5xmp2+v0qNGbQP EC4mqqiQAz2heupkjq2oqkBuGVQcNmfDVbors= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=in-reply-to:references:mime-version:content-type:message-id:cc :content-transfer-encoding:from:subject:date:to:x-mailer; b=OzxtnUV7He3fGywHcjamZ9NFrZVO8q9S8VGcR6p2URXbb0EWaXm0gllX7AdVsGsc82 nUq1vuGj5DRWRl5GU6MIVuY6RDFa9TYqJSp9S926WD2DujA1WDHSWGyQOnmhLY3q2VWd 5j/OqzxDORnillpiptujwx/uu+ux7BEJvw4H4= Received: by 10.114.210.3 with SMTP id i3mr5140197wag.186.1241519803030; Tue, 05 May 2009 03:36:43 -0700 (PDT) Received: from ?10.174.91.31? ([203.146.63.184]) by mx.google.com with ESMTPS id v25sm11317088wah.67.2009.05.05.03.36.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 May 2009 03:36:42 -0700 (PDT) In-Reply-To: <2E6E5869-2F70-4AF5-A917-7EA863D6BD42@gmail.com> References: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com> <87d4aowc1l.fsf@cyd.mit.edu> <2E6E5869-2F70-4AF5-A917-7EA863D6BD42@gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1ACB40A8-4422-4B9A-A0F7-FE0B9C738299@gmail.com> Cc: Chong Yidong , 2530@debbugs.gnu.org, Ian Eure , Emacs-Devel devel Content-Transfer-Encoding: 7bit From: Adrian Robert Subject: Re: 23/NS: redraws according to mouse-face are slow Date: Tue, 5 May 2009 17:36:31 +0700 To: David Reitter X-Mailer: Apple Mail (2.753.1) On May 5, 2009, at 10:37 AM, David Reitter wrote: > On May 4, 2009, at 9:53 PM, Chong Yidong wrote: > >> I see. It seems ns_draw_glyph_string is a lot more expensive that >> x_draw_glyph_string. The show_mouse_face function assumes that the >> *_draw_glyph_string operation is relatively cheap, which is why it's >> called inside a loop. >> >> My guess is that the problem lies in the calls to ns_focus and >> ns_unfocus in ns_draw_glyph_string. > > Right - but we still need them, at least for clipping. > That said, because of the clipping, calls to ns_focus may be more > expensive than desirable. We have multiple calls to > ns_draw_glyph_string, often more than one for each row, but we only > need one clipping for the whole frame. So, ideally we'd call > ns_focus outside the loops that call ns_draw_glyph_string, but the > architecture won't allow that. > >>> If we wrap the code in show_mouse_face in NS[Dis|En]ableScreen, the >>> problem goes away for me (and it's not just delayed). Same for the >>> header-line/overlay issues I reported in #2530. >> >> If possible, we should minimize the amount of platform-dependent code >> inside xdisp.c. Could you experiment with putting these calls >> somewhere >> in nsterm.m, say surrounding the calls to note_mouse_highlight? >> >> Also, could it be ns_update_begin and ns_update_end that you want to >> call, instead of NSDisableScreen and NSEnableScreen? > > Yes, sure, this variant works well, and it takes care of the ugly > flicker as well. > (However, when moving the mouse over a piece of text with (common) > mouse-face property, we shouldn't need to redraw in the first > place, and that should be addressed at some point, perhaps after > 23.1.) That ns_update_begin() acheives the same effect suggests that perhaps the core mouse face code should do this (through the RIF). ns_draw_glyph_string() is not slow for any other operations, despite the fact that it is called with the same granularity (same-face-glyph- run) everywhere, likely because the update_begin()/end() batching is used. (And yes, thanks for tracking this David!) -Adrian From cyd@stupidchicken.com Tue May 5 07:13:08 2009 Received: (at 2530) by emacsbugs.donarmstrong.com; 5 May 2009 14:13:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=AWL,GMAIL autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n45ED4fK006125 for <2530@emacsbugs.donarmstrong.com>; Tue, 5 May 2009 07:13:06 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 531CC57E24B; Tue, 5 May 2009 10:13:12 -0400 (EDT) From: Chong Yidong To: Adrian Robert Cc: David Reitter , 2530@debbugs.gnu.org, "\ Ian Eure" , Emacs-Devel devel Subject: Re: 23/NS: redraws according to mouse-face are slow References: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com> <87d4aowc1l.fsf@cyd.mit.edu> <2E6E5869-2F70-4AF5-A917-7EA863D6BD42@gmail.com> <1ACB40A8-4422-4B9A-A0F7-FE0B9C738299@gmail.com> Date: Tue, 05 May 2009 10:13:12 -0400 In-Reply-To: <1ACB40A8-4422-4B9A-A0F7-FE0B9C738299@gmail.com> (Adrian Robert's message of "Tue, 5 May 2009 17:36:31 +0700") Message-ID: <87ab5rvds7.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Adrian Robert writes: > That ns_update_begin() acheives the same effect suggests that perhaps > the core mouse face code should do this (through the RIF). Yes, show_mouse_face (or one of its callers) should probably call update_begin and update_end. But it's a little far along in the pretest to risk that. I'll make a note of revisiting this after the release. Could either your or David check in the nsterm.m fix, assuming no other problems turn up with it? From david.reitter@gmail.com Tue May 5 10:32:50 2009 Received: (at 2530) by emacsbugs.donarmstrong.com; 5 May 2009 17:32:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.4 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n45HWk4Y031873 for <2530@emacsbugs.donarmstrong.com>; Tue, 5 May 2009 10:32:47 -0700 Received: by qw-out-2122.google.com with SMTP id 5so4332796qwd.13 for <2530@emacsbugs.donarmstrong.com>; Tue, 05 May 2009 10:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=MuW5F0Q51iLYdTl7S7CfEf/o/worsETrqyK3Zv1ZDsg=; b=IHS1T72Fm7rb6+SCHQnPiWXcNnxkTjZBuNRMTVewbzMy4TZOIpk0z6YygY0KMtHhh0 fCrHZktnhNr8ZZ0brte3kNLxB9BNt+bgF8AqK2USkYQ8eIkRbCdRbLVieq9+D70JYy9K G/wPp4xu62CniHFBc8LC1T6csV0nKahmAHcaM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=EjVMBosazeyQRl0sENrwrnlM+ovQ2JiTLre8FStCMP+jgWS3Ve6V6TewFSSkKGq/YE rnillhDWyfpZwrVdz1aeMZhoDy2ZJ3xu5ki7b+KEriFufUU1qVRvQVa0ox/BvfzML1jv R/CuhadEFjD7qQD3fzidUgu+3ij7a8mFfDSkk= Received: by 10.224.60.203 with SMTP id q11mr399856qah.245.1241544766130; Tue, 05 May 2009 10:32:46 -0700 (PDT) Received: from SCARLETT.PSY.CMU.EDU (SCARLETT.PSY.CMU.EDU [128.2.249.106]) by mx.google.com with ESMTPS id 8sm290546qwj.21.2009.05.05.10.32.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 May 2009 10:32:45 -0700 (PDT) Cc: Adrian Robert , 2530@debbugs.gnu.org, "\ Ian Eure" , Emacs-Devel devel Message-Id: <48600A00-7FAE-4B80-8B3D-6615230918AF@gmail.com> From: David Reitter To: Chong Yidong In-Reply-To: <87ab5rvds7.fsf@cyd.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: 23/NS: redraws according to mouse-face are slow Date: Tue, 5 May 2009 13:32:43 -0400 References: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com> <87d4aowc1l.fsf@cyd.mit.edu> <2E6E5869-2F70-4AF5-A917-7EA863D6BD42@gmail.com> <1ACB40A8-4422-4B9A-A0F7-FE0B9C738299@gmail.com> <87ab5rvds7.fsf@cyd.mit.edu> X-Mailer: Apple Mail (2.930.3) On May 5, 2009, at 10:13 AM, Chong Yidong wrote: > Could either your or David check in the nsterm.m fix, assuming no > other > problems turn up with it? I will test it for a day or two, but check it in soon. I still think there are other places where the same technique would be beneficial, but they would be outside of ns*.m, albeit in #ifdefs. From the sound of your messages, I take it we'll hold off on that. Getting back to Ian's original point: Overall, if we were to release now, I would consider the NS port "usable", but "experimental" rather than "stable". From mituharu@math.s.chiba-u.ac.jp Tue May 5 17:50:28 2009 Received: (at 2530) by emacsbugs.donarmstrong.com; 6 May 2009 00:50:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,GMAIL autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from mathmail.math.s.chiba-u.ac.jp (ntp.math.s.chiba-u.ac.jp [133.82.132.2]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n460oMfv029592 for <2530@emacsbugs.donarmstrong.com>; Tue, 5 May 2009 17:50:24 -0700 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 1B6AE2C40; Wed, 6 May 2009 09:50:21 +0900 (JST) Date: Wed, 06 May 2009 09:50:21 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Adrian Robert Cc: David Reitter , 2530@debbugs.gnu.org, Chong Yidong , Ian Eure , Emacs-Devel devel Subject: Re: 23/NS: redraws according to mouse-face are slow In-Reply-To: <1ACB40A8-4422-4B9A-A0F7-FE0B9C738299@gmail.com> References: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com> <87d4aowc1l.fsf@cyd.mit.edu> <2E6E5869-2F70-4AF5-A917-7EA863D6BD42@gmail.com> <1ACB40A8-4422-4B9A-A0F7-FE0B9C738299@gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII >>>>> On Tue, 5 May 2009 17:36:31 +0700, Adrian Robert said: > That ns_update_begin() acheives the same effect suggests that > perhaps the core mouse face code should do this (through the RIF). > ns_draw_glyph_string() is not slow for any other operations, despite > the fact that it is called with the same granularity > (same-face-glyph- run) everywhere, likely because the > update_begin()/end() batching is used. The effect of ns_update_begin seems to avoid -[NSWindow flushWindow] call (via ns_unfocus) for each ns_draw_glyph_string call. Does this frequent flushing necessary in the first place? Other terms don't seem to do flushing for each string drawing call. YAMAMOTO Mitsuharu mituharu@math.s.chib-u.ac.jp From monnier@iro.umontreal.ca Tue May 5 18:47:13 2009 Received: (at 2530) by emacsbugs.donarmstrong.com; 6 May 2009 01:47:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.1 required=4.0 tests=AWL,XIRONPORT autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n461lAf6013589 for <2530@emacsbugs.donarmstrong.com>; Tue, 5 May 2009 18:47:11 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUFAECIAErO+IYe/2dsb2JhbACBUM4WhAEFhU4 X-IronPort-AV: E=Sophos;i="4.40,300,1238990400"; d="scan'208";a="38048633" Received: from 206-248-134-30.dsl.teksavvy.com (HELO ceviche.home) ([206.248.134.30]) by ironport2-out.teksavvy.com with ESMTP; 05 May 2009 21:47:04 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 92840B523F; Tue, 5 May 2009 21:47:04 -0400 (EDT) From: Stefan Monnier To: Chong Yidong Cc: Adrian Robert , 2530@debbugs.gnu.org, David Reitter , Ian Eure , Emacs-Devel devel Subject: Re: 23/NS: redraws according to mouse-face are slow Message-ID: References: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com> <87d4aowc1l.fsf@cyd.mit.edu> <2E6E5869-2F70-4AF5-A917-7EA863D6BD42@gmail.com> <1ACB40A8-4422-4B9A-A0F7-FE0B9C738299@gmail.com> <87ab5rvds7.fsf@cyd.mit.edu> Date: Tue, 05 May 2009 21:47:04 -0400 In-Reply-To: <87ab5rvds7.fsf@cyd.mit.edu> (Chong Yidong's message of "Tue, 05 May 2009 10:13:12 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> That ns_update_begin() acheives the same effect suggests that perhaps >> the core mouse face code should do this (through the RIF). > Yes, show_mouse_face (or one of its callers) should probably call > update_begin and update_end. But it's a little far along in the pretest > to risk that. I'll make a note of revisiting this after the release. I think as long as this is guaranteed to only affect the NS port, we can still install it before the release (assuming tests indicate it does improve the behavior, and assuming we agree that it's the right way to fix it). Stefan From adrian.b.robert@gmail.com Tue May 5 18:55:59 2009 Received: (at 2530) by emacsbugs.donarmstrong.com; 6 May 2009 01:55:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.5 required=4.0 tests=AWL,GMAIL autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-fx0-f160.google.com (mail-fx0-f160.google.com [209.85.220.160]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n461tt9n016279 for <2530@emacsbugs.donarmstrong.com>; Tue, 5 May 2009 18:55:56 -0700 Received: by fxm4 with SMTP id 4so6114860fxm.1 for <2530@emacsbugs.donarmstrong.com>; Tue, 05 May 2009 18:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:in-reply-to:references :mime-version:content-type:message-id:cc:content-transfer-encoding :from:subject:date:to:x-mailer; bh=JG+nGV1d+ZSG+C8PDPsUUdxCdVbpMqFm7W12ygbrzTg=; b=lUyzm0flab/RU4Yk9CYtgT2MdZqDgAeOUYfQhy/BjK0VAbp5IxVBbSF90/IANB6bXd 2Giv3FrslnWwH8YTnUElxc2VnFgGMhAj5RjeKBFXC9z+lRFUHkJRy8v2qZbbRKNdTbes QRcw57YWCJ/LBF02neMwL8NIK6b9/fxsSvOF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=in-reply-to:references:mime-version:content-type:message-id:cc :content-transfer-encoding:from:subject:date:to:x-mailer; b=NIPsqtwMvApA/zLzcQd6ODpfYPT0lpy5dPTL78Rlhdi09B3fo+CDQTAFqFA5CL62wd gBVwehSsbreQVk//69XY7N0t3zeBolZMzFhk+sdTotImPGTWniQYFLwP0ghCrL3OLvJJ euyGspPVFkGqzLU4BHMa1R4PSgOjiE8Fq/yD4= Received: by 10.204.66.17 with SMTP id l17mr696908bki.51.1241574949387; Tue, 05 May 2009 18:55:49 -0700 (PDT) Received: from ?10.174.219.228? ([203.146.63.183]) by mx.google.com with ESMTPS id 28sm12401625fkx.28.2009.05.05.18.55.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 May 2009 18:55:48 -0700 (PDT) In-Reply-To: References: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com> <87d4aowc1l.fsf@cyd.mit.edu> <2E6E5869-2F70-4AF5-A917-7EA863D6BD42@gmail.com> <1ACB40A8-4422-4B9A-A0F7-FE0B9C738299@gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: David Reitter , 2530@debbugs.gnu.org, Chong Yidong , Emacs-Devel devel Content-Transfer-Encoding: 7bit From: Adrian Robert Subject: Re: 23/NS: redraws according to mouse-face are slow Date: Wed, 6 May 2009 08:55:36 +0700 To: YAMAMOTO Mitsuharu X-Mailer: Apple Mail (2.753.1) On May 6, 2009, at 7:50 AM, YAMAMOTO Mitsuharu wrote: >>>>>> On Tue, 5 May 2009 17:36:31 +0700, Adrian Robert >>>>>> said: > >> That ns_update_begin() acheives the same effect suggests that >> perhaps the core mouse face code should do this (through the RIF). >> ns_draw_glyph_string() is not slow for any other operations, despite >> the fact that it is called with the same granularity >> (same-face-glyph- run) everywhere, likely because the >> update_begin()/end() batching is used. > > The effect of ns_update_begin seems to avoid -[NSWindow flushWindow] > call (via ns_unfocus) for each ns_draw_glyph_string call. Does this > frequent flushing necessary in the first place? Other terms don't > seem to do flushing for each string drawing call. My assumption was that it is legal to call draw_glyph_string() outside of an update_begin()-end() pair. So draw_glyph_string() must be able to operate in "self-contained" mode, which and the flush is needed. The same logic holds for other RIF functions -- that they can either be called in one-shot mode or in batch mode (inside update begin-end). In the latter case, focus/unfocus reflect the batching by holding screen flush until end. Emacs core seems to batch most/all other sets of operations done at once as part of a single redisplay. It may be that screen update batching is handled implicitly by the window system for X, so the distinction doesn't get made in the code there. Some behavior in this area differs between MacOS and GNUstep (as may be seen, e.g., from the ifdefs in ns_[un]focus]), so any changes made should be tested on both platforms before committing. From mituharu@math.s.chiba-u.ac.jp Tue May 5 19:25:40 2009 Received: (at 2530) by emacsbugs.donarmstrong.com; 6 May 2009 02:25:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.2 required=4.0 tests=AWL,FOURLA,GMAIL autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from mathmail.math.s.chiba-u.ac.jp (mathmail.math.s.chiba-u.ac.jp [133.82.132.2]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n462Padu024639 for <2530@emacsbugs.donarmstrong.com>; Tue, 5 May 2009 19:25:37 -0700 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 0D0E42C40; Wed, 6 May 2009 11:25:36 +0900 (JST) Date: Wed, 06 May 2009 11:25:35 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Adrian Robert Cc: David Reitter , 2530@debbugs.gnu.org, Chong Yidong , Emacs-Devel devel Subject: Re: 23/NS: redraws according to mouse-face are slow In-Reply-To: References: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com> <87d4aowc1l.fsf@cyd.mit.edu> <2E6E5869-2F70-4AF5-A917-7EA863D6BD42@gmail.com> <1ACB40A8-4422-4B9A-A0F7-FE0B9C738299@gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII >>>>> On Wed, 6 May 2009 08:55:36 +0700, Adrian Robert said: >> The effect of ns_update_begin seems to avoid -[NSWindow >> flushWindow] call (via ns_unfocus) for each ns_draw_glyph_string >> call. Does this frequent flushing necessary in the first place? >> Other terms don't seem to do flushing for each string drawing call. > My assumption was that it is legal to call draw_glyph_string() > outside of an update_begin()-end() pair. So draw_glyph_string() > must be able to operate in "self-contained" mode, which and the > flush is needed. The same logic holds for other RIF functions -- > that they can either be called in one-shot mode or in batch mode > (inside update begin-end). In the latter case, focus/unfocus > reflect the batching by holding screen flush until end. Other terms don't do flushing even at update_end, let alone at the end of each one-shot drawing operation (you may see XFlush calls in the code but they are mostly defined as no-ops). IIUC, flushing happens only by explicit flush_display(_optional) RIF calls or at the timing of polling/receiving window system events (e.g., XPending on X11, and ReceiveNextEvent on Carbon) implicitly. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From mituharu@math.s.chiba-u.ac.jp Wed May 6 00:40:58 2009 Received: (at 2530) by emacsbugs.donarmstrong.com; 6 May 2009 07:40:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mathmail.math.s.chiba-u.ac.jp (ntp.math.s.chiba-u.ac.jp [133.82.132.2]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n467esln016779 for <2530@emacsbugs.donarmstrong.com>; Wed, 6 May 2009 00:40:55 -0700 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id D26B12C40; Wed, 6 May 2009 16:40:52 +0900 (JST) Date: Wed, 06 May 2009 16:40:52 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Stefan Monnier Cc: Chong Yidong , 2530@debbugs.gnu.org, David Reitter , Ian Eure , Adrian Robert , Emacs-Devel devel Subject: Re: 23/NS: redraws according to mouse-face are slow In-Reply-To: References: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com> <87d4aowc1l.fsf@cyd.mit.edu> <2E6E5869-2F70-4AF5-A917-7EA863D6BD42@gmail.com> <1ACB40A8-4422-4B9A-A0F7-FE0B9C738299@gmail.com> <87ab5rvds7.fsf@cyd.mit.edu> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII >>>>> On Tue, 05 May 2009 21:47:04 -0400, Stefan Monnier said: >>> That ns_update_begin() acheives the same effect suggests that >>> perhaps the core mouse face code should do this (through the RIF). >> Yes, show_mouse_face (or one of its callers) should probably call >> update_begin and update_end. But it's a little far along in the >> pretest to risk that. I'll make a note of revisiting this after >> the release. > I think as long as this is guaranteed to only affect the NS port, we > can still install it before the release (assuming tests indicate it > does improve the behavior, and assuming we agree that it's the right > way to fix it). That introduces nesting in update_begin/end. We should avoid such a change at this stage. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 14 00:08:38 2016 Received: (at 2530) by debbugs.gnu.org; 14 Jan 2016 05:08:38 +0000 Received: from localhost ([127.0.0.1]:48742 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aJa9G-0003uW-1m for submit@debbugs.gnu.org; Thu, 14 Jan 2016 00:08:38 -0500 Received: from mail-qk0-f173.google.com ([209.85.220.173]:33757) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aJa9F-0003uJ-27 for 2530@debbugs.gnu.org; Thu, 14 Jan 2016 00:08:37 -0500 Received: by mail-qk0-f173.google.com with SMTP id p186so200115591qke.0 for <2530@debbugs.gnu.org>; Wed, 13 Jan 2016 21:08:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=YrjEI5BGGrjzjl2FNPPYWeRl/S+bLsfhO1i2v5cQjhE=; b=FVK6/1HegOFPvnKBitacGVQQ6nCUA9rVC1s3/z5j6VUXczsubl7xrl/NZ3maU/SMJO EFH7TLz3P7RYedSyE8sTaTZC2FvRzhhi6+qSmJI8+zmsmDEAiMB+ScfqK7BHt/YVqHdw zUtOU9HUN4gs4rUvZ6ssUkP2A6wgDaI1QNfKEuuYdEfR4ZrK7nBS2JrxFFVPH9O/5su/ 9zNnQxgLvBSDKskGtG4WxgwaoS4bfuApJIWziPv/Pg/eMCs5usPXBQnGeSdkLFbqxCXQ 5Ej74gYsIlDBnEIdyjuzwfKLUrXm43/lyXp5uL8cKbzzYKfna2RGSjFmiBN3dISU3sgV Pltw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=YrjEI5BGGrjzjl2FNPPYWeRl/S+bLsfhO1i2v5cQjhE=; b=bDBwMCyNOVjSD+CYuKwkQ3qmXpZwFvkEgwLAeunjIethLA8PJd4p5TqfzxJe+aUnhR 71RyVYJmCV9Hj7fIyXi4rVze/BkhnnTfoB+VXaqyHiCeFVKfiUaDbKqKtDTTTFjmhmbZ wUeyV0wx2zbsNQ38nymRB1IplesvI4id9QkbCCi+Qh3d/lBNwq18U668k96fadxndM92 U0c3Rmv4J7g0RybwA7BlSxnxJ9XAXA7c1vTRQKaYGNzapx+dcmJNv9Oml63Wnx92Wadv Jz5JF59ltBE0kmhF5K0bWQPQRKCqvED+afnyOkDis/pEtKkePOICd9kCE/A74CxuhkmR If4Q== X-Gm-Message-State: ALoCoQnaNU8Jjy0X1YaKUvancCn8/l+leFlDJpx/ukTnmz7S0Qroyxat60oW3l9uSuwCljOe3VjZfye2xDNC8AajwZ7oQRqmiw== X-Received: by 10.55.72.77 with SMTP id v74mr2541490qka.88.1452748111406; Wed, 13 Jan 2016 21:08:31 -0800 (PST) Received: from Andrews-MacBook-Pro.local.ahyatt-laptop (cpe-74-73-128-199.nyc.res.rr.com. [74.73.128.199]) by smtp.gmail.com with ESMTPSA id b95sm1864097qge.47.2016.01.13.21.08.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jan 2016 21:08:30 -0800 (PST) From: Andrew Hyatt To: David Reitter Subject: Re: bug#2530: 23/NS: redraws according to mouse-face are slow References: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com> <87d4aowc1l.fsf@cyd.mit.edu> <2E6E5869-2F70-4AF5-A917-7EA863D6BD42@gmail.com> <1ACB40A8-4422-4B9A-A0F7-FE0B9C738299@gmail.com> <87ab5rvds7.fsf@cyd.mit.edu> <48600A00-7FAE-4B80-8B3D-6615230918AF@gmail.com> Date: Thu, 14 Jan 2016 00:08:27 -0500 In-Reply-To: <48600A00-7FAE-4B80-8B3D-6615230918AF@gmail.com> (David Reitter's message of "Tue, 5 May 2009 13:32:43 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 2530 Cc: 2530@debbugs.gnu.org, Chong Yidong , Adrian Robert , Ian Eure , Emacs-Devel devel 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: -0.7 (/) There's a bunch of discussion before, in 2009, but as of now, for Emacs 25, I don't notice any particular slowness on El Capitan. Can anyone still reproduce a problem here? David Reitter writes: > On May 5, 2009, at 10:13 AM, Chong Yidong wrote: > >> Could either your or David check in the nsterm.m fix, assuming no other >> problems turn up with it? > > I will test it for a day or two, but check it in soon. > > I still think there are other places where the same technique would be > beneficial, but they would be outside of ns*.m, albeit in #ifdefs. From the > sound of your messages, I take it we'll hold off on that. > > Getting back to Ian's original point: Overall, if we were to release now, I > would consider the NS port "usable", but "experimental" rather than "stable". From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 14 00:08:48 2016 Received: (at control) by debbugs.gnu.org; 14 Jan 2016 05:08:48 +0000 Received: from localhost ([127.0.0.1]:48745 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aJa9Q-0003uy-8T for submit@debbugs.gnu.org; Thu, 14 Jan 2016 00:08:48 -0500 Received: from mail-qg0-f42.google.com ([209.85.192.42]:36149) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aJa9P-0003un-BY for control@debbugs.gnu.org; Thu, 14 Jan 2016 00:08:47 -0500 Received: by mail-qg0-f42.google.com with SMTP id e32so383876590qgf.3 for ; Wed, 13 Jan 2016 21:08:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:message-id:to:from:subject; bh=K+Xb/LfpcVQX+PIOKMSd+rrz3/Q2m05HXwhHf9YyzPw=; b=STjxDVvisqEMtQ3Fdv4qRTlajFUXUqmu53IY4WC+DyEddZ0CLWF/X89fMc5TNH0zdD HXLljVpMsdl0+53mB365XEGj/aE3B/tjyEK9kB4qVdC6y8SAFlggwKqCQMhzYNl2GwPM SOUlBvvcMe2+hwNaqAQUm+aM0olEIwQsR4bTduhYrDHvoqEgvD4wwbFz8djS2vup7TIs fPpnVJhEncsIC7mSxMSjoTerIqSm7Iawa937zaElvGfkY54+C4qI/GKiQr1xShNUJSU0 mkaUFjyNYCjr6P6P09IugdRRc9Eq4FLkChi/gg/hsae7XbNcx6PxIISjHfdP8iFo1BzK GS/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:message-id:to:from:subject; bh=K+Xb/LfpcVQX+PIOKMSd+rrz3/Q2m05HXwhHf9YyzPw=; b=YDIwcZO/9QXryOsQAYwj6HN4xDyFAa0f/6YWyDwG+V0wRlASY75bBAIsN6yZnFxYPL t/EoRThnApZaKNSQxsRaymHplbhu52k/ZSkJtIkWGvURV9vId+cLSkw6pkPEXxw+/BdA UzHaCHJIDs0A/g7s2O6KPxtoeKHJcgZcnUmikydbrIogtbWcOhS+MeGQtM4753bh+Vhi d1r7NGXrSnjwRhNonUmll6h3ZXQDsl/SWhzk96U2KhJtWp7wfe0mzl7lhWXy33hxU6Bq iNGjvYMVICfx0TaTk4e9JvD5cT47tn7F6Cms1u2Zml1emuUxdvdIzzZdoTQwsoecVUII lqpA== X-Gm-Message-State: ALoCoQkZw0LEewnPkuH7709kANBUhrHo0Hm5GESIXfo7c0OR6PDJC3q1RfXSK1yJp9RbUd/Cnl3dWNp4RilYGoA/ooz3pXfh+Q== X-Received: by 10.140.148.81 with SMTP id 78mr2699880qhu.17.1452748121847; Wed, 13 Jan 2016 21:08:41 -0800 (PST) Received: from Andrews-MacBook-Pro.local.ahyatt-laptop (cpe-74-73-128-199.nyc.res.rr.com. [74.73.128.199]) by smtp.gmail.com with ESMTPSA id 187sm1881165qhi.0.2016.01.13.21.08.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jan 2016 21:08:41 -0800 (PST) Date: Thu, 14 Jan 2016 00:08:38 -0500 Message-Id: To: control@debbugs.gnu.org From: Andrew Hyatt Subject: control message for bug #2530 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: control 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: -0.7 (/) tags 2530 unreproducible From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 14 15:34:33 2016 Received: (at 2530) by debbugs.gnu.org; 14 Jan 2016 20:34:33 +0000 Received: from localhost ([127.0.0.1]:49428 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aJobJ-0005Ua-3J for submit@debbugs.gnu.org; Thu, 14 Jan 2016 15:34:33 -0500 Received: from mail-wm0-f50.google.com ([74.125.82.50]:33917) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aJobG-0005UL-SM for 2530@debbugs.gnu.org; Thu, 14 Jan 2016 15:34:31 -0500 Received: by mail-wm0-f50.google.com with SMTP id u188so364172792wmu.1 for <2530@debbugs.gnu.org>; Thu, 14 Jan 2016 12:34:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=pvbKAc6Y/047hwD/mFHKdxtv7Adb3hsFRSnj7NSZum8=; b=NLR62XKKWtEi8bBEW0i3eL9C+jtSnmIahLYDsxgn/ans8qUci8X20MrNT8CvRZWFkz FuLrDH+unWg7ovzLqYOWa0XqNLVsB7hunad2XgInQMZ2WAbNHhd0lAvK6FQJgx5gtPRf 0kCUi9rb1SMZLAMN7DpJV+JCjjlObCGmnb/9pQj21RyJyVFepgEuGCMd1W/5VFBxhoUW X19Tlju32nkPyovmNgEoAqxV6zPUlqlr1iYo0bTvaD06xY3cS3UXzdfvdCX7Gmqx/7qI /tNgvp6dEpPfddxQWlj57YMt/5SiAjZ04d8+dTY0T7rVkOQKIX3QbjXDPM+gd5Gum4SV Jvlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version:content-type; bh=pvbKAc6Y/047hwD/mFHKdxtv7Adb3hsFRSnj7NSZum8=; b=enno6KNNQCUXWl3jbLhzAzuVzV9NzVxia6WKDVKN+0nNnjl/+Sba8pkrqK9JA78w0t 9ShM/K4AmaW5ywBOOIohMRcJHAUw3WSYYtKhWkvCn+E/bOnD/1cBUAGxGGORUNDEvR1i 1MILGM+Gz16qDg9ihtlDV/FStIUxj4WjcsoDv9U6Fbk/Vo2hD5lNkfvYYydwXHfJUYOV jSOsR3aYApybYPWEjlTi+g5BZwFqdJurt10yE9bK5gb54vPEYqYILqwsG++9bL1iDAtA RJ8jCwPNCvfneUX0ikXXZ2IVlm/tZ52K+NDY5XeXOAAtp0c+mM7uEhGCqCqjke9FS+VD 4+FQ== X-Gm-Message-State: ALoCoQmTnOYF/j9cVHkOjBcwDqsCaJvE5XnHuFPAUtekB9YaUrsfOXvW9X2nllsXxmgpAphNuWW9bg+cYI3NE1pqDuQxDTk/fQ== X-Received: by 10.194.119.68 with SMTP id ks4mr5897526wjb.45.1452803665320; Thu, 14 Jan 2016 12:34:25 -0800 (PST) Received: from galloway.idiocy.org (c.6.b.f.c.c.b.1.0.4.a.0.d.a.5.e.9.2.1.8.8.f.3.0.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:3f8:8129:e5ad:a40:1bcc:fb6c]) by smtp.gmail.com with ESMTPSA id q129sm8815569wmd.14.2016.01.14.12.34.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jan 2016 12:34:24 -0800 (PST) From: Alan J Third To: Andrew Hyatt Subject: Re: bug#2530: 23/NS: redraws according to mouse-face are slow References: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com> <87d4aowc1l.fsf@cyd.mit.edu> <2E6E5869-2F70-4AF5-A917-7EA863D6BD42@gmail.com> <1ACB40A8-4422-4B9A-A0F7-FE0B9C738299@gmail.com> <87ab5rvds7.fsf@cyd.mit.edu> <48600A00-7FAE-4B80-8B3D-6615230918AF@gmail.com> Date: Thu, 14 Jan 2016 20:34:22 +0000 In-Reply-To: (Andrew Hyatt's message of "Thu, 14 Jan 2016 00:08:27 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 2530 Cc: 2530@debbugs.gnu.org, Ian Eure , David Reitter , Chong Yidong , Emacs-Devel devel , Adrian Robert 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: -0.5 (/) Andrew Hyatt writes: > There's a bunch of discussion before, in 2009, but as of now, for Emacs > 25, I don't notice any particular slowness on El Capitan. Can anyone > still reproduce a problem here? > > David Reitter writes: > >> On May 5, 2009, at 10:13 AM, Chong Yidong wrote: >> >>> Could either your or David check in the nsterm.m fix, assuming no other >>> problems turn up with it? >> >> I will test it for a day or two, but check it in soon. >> >> I still think there are other places where the same technique would be >> beneficial, but they would be outside of ns*.m, albeit in #ifdefs. From the >> sound of your messages, I take it we'll hold off on that. >> >> Getting back to Ian's original point: Overall, if we were to release now, I >> would consider the NS port "usable", but "experimental" rather than "stable". David Reitter has a number of open bug reports about redraw slowness on OS X and I can't replicate any of the ones I've looked at. I don't know if the display code's been rewritten or something? -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 14 16:00:45 2016 Received: (at 2530) by debbugs.gnu.org; 14 Jan 2016 21:00:45 +0000 Received: from localhost ([127.0.0.1]:49432 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aJp0f-000663-73 for submit@debbugs.gnu.org; Thu, 14 Jan 2016 16:00:45 -0500 Received: from mail-qg0-f51.google.com ([209.85.192.51]:34397) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aJp0d-00065r-Jx for 2530@debbugs.gnu.org; Thu, 14 Jan 2016 16:00:43 -0500 Received: by mail-qg0-f51.google.com with SMTP id 6so414444108qgy.1 for <2530@debbugs.gnu.org>; Thu, 14 Jan 2016 13:00:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Vauq7GX2Hr94k6CBUeSZ4zbvME2ielfl/xpyYXtCkWE=; b=SP6YpdNfKZ1iP9Sp5MqpW/5XE0g+xyCjo9eF3uj3/8OFKfTQq7rICmg5YWEh9CY73i oBMwjgFG7CzYE8GqjPlbmpiEWOMHOXyQGrTrdiaiuFUcm4V+QmUKLbURRziZ09Ur7erZ nBmAQWyuxkSjUWOn/NRxDop99F9mpgdw5liJPjViN0BjEFiha9qJozg+50PjzPQ+4s/C gghEiOMVbM0s5Ga7NcsPKKbDICw3w2qhl0mcsJqs5Knsng68eYuNwUKGst/L8z8yEREy v5AYy2glLjeg42N8/ccrGoYgAcgKpU8+pYqsBnmTwJ8NKkU67E0OO9lv2wnPOVJY5IU4 miYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Vauq7GX2Hr94k6CBUeSZ4zbvME2ielfl/xpyYXtCkWE=; b=HAarkALpz4PAUrIy4cBJhUZWTpI6ZkCjmKCbbU5Ko175oy/5411xRkgHewyXRwfFG8 LtXN7Y4U0PqIiIH6EIw+NvUZjdIJ8jbjn9iuKWF606PrLj902b6w7AMmskAb/y2iMqs0 BpdLrVrISBzbaOTjDM7xsyrAQ7OQz/0SIOnTreFeFOUTMvzUpmyBVRz8tLT77UmhYfqM LvgxdWKufgaMwemSEzBOy5Odidq1rMy+IfxNwzBr/3njBLcWXdpg408BAWHAsYYNtpah VyhTfD7RzpFmiRPyinupTbLtX99z+Xo1xcM7OXSFX3yh/Knsh3BMbVgVz4YiaWeiSorc ocfQ== X-Gm-Message-State: ALoCoQknRuJXqhaJMHJuqXNijNDMlB79ya0NagKFg53L8xEuxxyGNB22glHF8Qj3e2jVs5ernwy+S6EBIon4Rul7DgXkK+tZqw== X-Received: by 10.140.16.225 with SMTP id 88mr8886170qgb.96.1452805237965; Thu, 14 Jan 2016 13:00:37 -0800 (PST) Received: from [130.203.152.247] ([130.203.152.247]) by smtp.gmail.com with ESMTPSA id s103sm3204066qge.3.2016.01.14.13.00.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Jan 2016 13:00:36 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: bug#2530: 23/NS: redraws according to mouse-face are slow From: David Reitter In-Reply-To: Date: Thu, 14 Jan 2016 16:00:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com> <87d4aowc1l.fsf@cyd.mit.edu> <2E6E5869-2F70-4AF5-A917-7EA863D6BD42@gmail.com> <1ACB40A8-4422-4B9A-A0F7-FE0B9C738299@gmail.com> <87ab5rvds7.fsf@cyd.mit.edu> <48600A00-7FAE-4B80-8B3D-6615230918AF@gmail.com> To: Alan J Third X-Mailer: Apple Mail (2.3112) X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 2530 Cc: 2530@debbugs.gnu.org, Andrew Hyatt , Chong Yidong , Ian Eure , Emacs-Devel devel , Adrian Robert 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: -0.7 (/) > David Reitter has a number of open bug reports about redraw slowness = on > OS X and I can't replicate any of the ones I've looked at. I don't = know > if the display code's been rewritten or something? Most of these are really very old. Come to think of it, with the current codebase, I don=E2=80=99t recall = seeing these NS port slownesses. One thing worth testing would be the slowness that occurred with very = long lines. I apologize, but due to my schedule I can=E2=80=99t find = the according bug report and try to reproduce. =20= From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 14 16:46:02 2016 Received: (at 2530) by debbugs.gnu.org; 14 Jan 2016 21:46:02 +0000 Received: from localhost ([127.0.0.1]:49456 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aJpiU-0007Qo-0j for submit@debbugs.gnu.org; Thu, 14 Jan 2016 16:46:02 -0500 Received: from jugulator.defunced.de ([89.238.65.41]:53768) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aJpZ1-0007C4-D5 for 2530@debbugs.gnu.org; Thu, 14 Jan 2016 16:36:16 -0500 Received: from localhost (localhost [127.0.0.1]) by jugulator.defunced.de (Postfix) with ESMTP id 23B30726E039; Thu, 14 Jan 2016 22:36:14 +0100 (CET) X-Virus-Scanned: amavisd-new at defunct.ch Received: from jugulator.defunced.de ([127.0.0.1]) by localhost (painkiller.defunced.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeFUAAteC7DS; Thu, 14 Jan 2016 22:36:13 +0100 (CET) Received: from localhost (p54952D10.dip0.t-ipconnect.de [84.149.45.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by jugulator.defunced.de (Postfix) with ESMTPSA id 99E8F726E034; Thu, 14 Jan 2016 22:36:12 +0100 (CET) From: Christian Kruse To: Andrew Hyatt , David Reitter Subject: Re: bug#2530: 23/NS: redraws according to mouse-face are slow In-Reply-To: References: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com> <87d4aowc1l.fsf@cyd.mit.edu> <2E6E5869-2F70-4AF5-A917-7EA863D6BD42@gmail.com> <1ACB40A8-4422-4B9A-A0F7-FE0B9C738299@gmail.com> <87ab5rvds7.fsf@cyd.mit.edu> <48600A00-7FAE-4B80-8B3D-6615230918AF@gmail.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-unknown-linux-gnu) Date: Thu, 14 Jan 2016 22:39:20 +0100 Message-ID: <87r3hjrgc7.fsf@motte.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 2530 X-Mailman-Approved-At: Thu, 14 Jan 2016 16:46:01 -0500 Cc: 2530@debbugs.gnu.org, Chong Yidong , Adrian Robert , Ian Eure , Emacs-Devel devel 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: 0.0 (/) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Andrew Hyatt writes: > There's a bunch of discussion before, in 2009, but as of now, for Emacs > 25, I don't notice any particular slowness on El Capitan. Can anyone > still reproduce a problem here? Compared to Linux (the Linux hardware is slower, a Notebook from 2011 and the OS X notebook is a Macbook Pro Retina from 2014), the OS X version is *pretty* slow. While everything I do with Emacs is nearly instant when using Linux there is a notably delay when using Emacs with OS X. The worst example is Magit, which I already profiled because it is *so* slow: when using Linux `magit-status` shows up instantly. It takes about 1.5 seconds when using OS X (hold it, I am aware that this is not the place to discuss Magit performance, it is just an example :-) Every buffer with lots of lines (e.g. a notmuch buffer with 26k mails, my archive of the pg-hackers list) is lightning fast when using Linux, but takes round about 30 seconds when using OS X. Although I=E2=80=99m not sure that it is only the rendering engine (of cour= se it could also be the elisp interpreter being slower) it occurs to me that it plays its part: especially redraw actions seem to be very slow. For example mu4e is unbearable slow when displaying maildirs with a lot of mails (e.g. the 26k mails maildir I mentioned above) but works fine for small mailboxes; and while the content of the maildir is loading, the buffer is flickering all the time as if it gets redrawn all the time. Best regards, =2D-=20 Christian Kruse https://wwwtech.de/about --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWmBWIAAoJELjg80Kpmp1z6yEP/iUAkcI+VWOGmOZobhUJ7jKK BSW0BfO6oAt9ewjGXnTu13EITW4+hCNLeLIjPWy56z/wMPhYCXphuSFGIKUDKLj9 3tiPdaoQxMVvHiaV45ZcJEpgOwOLyFgSGgmbHqeLX3IikiM/fwaP49+2VaQ4bBPF OCB6anjxSKH7SIEIX/JWonkjSgRqq+ZfXGYarH4anXrLv4F1GtbGLdl6JxkM3WFi 8y8J0TabiaC4QwU2UyTxBLnMQM6LZ6SkB6Q1OCUumGw2dvYkMngBA1VP278kGHik ji58Xoog87dEdF+EN/JI9vh7Rli1fMexB4Wo8KoYONUJSQ/Ihm/TRGI4FgGQOlYa uDrXau/GBpk3XtRW4dqMkYx9KKw9xfAhjxq8V/4VO5IeAKxYUCjxcv874vHT/TAt 55U4trC1anmvtM9nTk11jQpoUv93W1jA1BOGBNhrTWOozyrIj3FJpLUGtQIAswG0 utMfQlRDfaY+b3ZV9/ML003xZqvYnIN0SJkJahxo8lr35A7+Hl3nXma30Bfsdniy 4GF7grfOpglaOzDa6OC/2GVdqrjVRLI6O7bP2LIzIwHq02bnAdNtNYjSqdEMwYaM 2d3w4leBGCg+Rh+vypfPeuscHTL7TwZDIUagR/S+69vn5USMhpJeSFI/XwbIGZ8/ fNUXGHBf3FITGEpONRpu =ZZM2 -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 15 02:38:55 2016 Received: (at 2530) by debbugs.gnu.org; 15 Jan 2016 07:38:55 +0000 Received: from localhost ([127.0.0.1]:49567 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aJyyE-0004ta-Ne for submit@debbugs.gnu.org; Fri, 15 Jan 2016 02:38:54 -0500 Received: from eggs.gnu.org ([208.118.235.92]:36638) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aJyyC-0004tM-OO for 2530@debbugs.gnu.org; Fri, 15 Jan 2016 02:38:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJyy5-0001jL-9G for 2530@debbugs.gnu.org; Fri, 15 Jan 2016 02:38:47 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33260) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJyxt-0001dW-RJ; Fri, 15 Jan 2016 02:38:33 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4510 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aJyxs-0005h4-DU; Fri, 15 Jan 2016 02:38:32 -0500 Date: Fri, 15 Jan 2016 09:38:29 +0200 Message-Id: <837fjbgumi.fsf@gnu.org> From: Eli Zaretskii To: Christian Kruse In-reply-to: <87r3hjrgc7.fsf@motte.fritz.box> (message from Christian Kruse on Thu, 14 Jan 2016 22:39:20 +0100) Subject: Re: bug#2530: 23/NS: redraws according to mouse-face are slow References: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com> <87d4aowc1l.fsf@cyd.mit.edu> <2E6E5869-2F70-4AF5-A917-7EA863D6BD42@gmail.com> <1ACB40A8-4422-4B9A-A0F7-FE0B9C738299@gmail.com> <87ab5rvds7.fsf@cyd.mit.edu> <48600A00-7FAE-4B80-8B3D-6615230918AF@gmail.com> <87r3hjrgc7.fsf@motte.fritz.box> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 2530 Cc: 2530@debbugs.gnu.org, ahyatt@gmail.com, david.reitter@gmail.com, cyd@stupidchicken.com, ian@digg.com, emacs-devel@gnu.org, adrian.b.robert@gmail.com 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: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Christian Kruse > Date: Thu, 14 Jan 2016 22:39:20 +0100 > Cc: 2530@debbugs.gnu.org, Chong Yidong , > Adrian Robert , > Ian Eure , Emacs-Devel devel > > Compared to Linux (the Linux hardware is slower, a Notebook from 2011 > and the OS X notebook is a Macbook Pro Retina from 2014), the OS X > version is *pretty* slow. While everything I do with Emacs is nearly > instant when using Linux there is a notably delay when using Emacs with > OS X. That's normal: GNU/Linux is significantly more efficient than other modern OSes. Nothing related to Emacs, really. > The worst example is Magit, which I already profiled because it is > *so* slow: when using Linux `magit-status` shows up instantly. It takes > about 1.5 seconds when using OS X (hold it, I am aware that this is not > the place to discuss Magit performance, it is just an example :-) Every > buffer with lots of lines (e.g. a notmuch buffer with 26k mails, my > archive of the pg-hackers list) is lightning fast when using Linux, but > takes round about 30 seconds when using OS X. Sounds like you describe a situation that is file I/O extensive. If so, again, there's little wonder you see much faster operation on GNU/Linux. If you'd say the same about comparison with MS-Windows, say, then it would be something worth investigating. > Although I’m not sure that it is only the rendering engine (of course it > could also be the elisp interpreter being slower) it occurs to me that > it plays its part: especially redraw actions seem to be very slow. For > example mu4e is unbearable slow when displaying maildirs with a lot of > mails (e.g. the 26k mails maildir I mentioned above) but works fine for > small mailboxes; and while the content of the maildir is loading, the > buffer is flickering all the time as if it gets redrawn all the time. The flickering you describe can only be triggered by platform-independent parts of the display engine, so again, this isn't OS X or NS specific, AFAIU. Emacs comes with a trace-redisplay command (compiled only if you configure Emacs --enable-testing='yes,glyphs'), so if someone wants to test the hypothesis that such flickering is specific to NS, they could run the same scenario on OS X and on another system, after invoking trace-redisplay, and compare the outputs. I'd expect them to be identical (except for the addresses it prints). From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 15 23:16:07 2016 Received: (at 2530) by debbugs.gnu.org; 16 Jan 2016 04:16:07 +0000 Received: from localhost ([127.0.0.1]:50342 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aKIHX-0000ct-6L for submit@debbugs.gnu.org; Fri, 15 Jan 2016 23:16:07 -0500 Received: from mail-qg0-f45.google.com ([209.85.192.45]:32994) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aKIHV-0000cB-Hy for 2530@debbugs.gnu.org; Fri, 15 Jan 2016 23:16:05 -0500 Received: by mail-qg0-f45.google.com with SMTP id b35so392851316qge.0 for <2530@debbugs.gnu.org>; Fri, 15 Jan 2016 20:16:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=qd6q1KnpRnn62gEDHflY/dA0RxTEnsQI8Xs5eAh5ATg=; b=HQw+hVXaxp+c7VxKWISSVVfDSeTvvGagpC6CNrz5Ef8xHt5N7V64s6vTM98MGwcQ9i SsJDqktKWtJrbqEdwF2INAK7INf6R5teW0PtrEw1AIMYrDl/342+wwe3+3wJYNPKLUon 3ZSfLJNujVOTHsZ468jJQPVEvLpCJsKC3Lo0UA8Lk1wzxj5hHXkQAKmaKRAQGKeumSVZ Ysz+ZXbB98xHjavuaXSOLnrHr7CaIpGINpygQ8KNaxwP4sBUgR4stvzm9RQuosTu7z0Z pXcBxAgBvCiquJ5hwPT4NiCougE96Aw5BhHKfV4oyI1sIyB/ULAmYm11/wommPX5aKp2 hj9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type :content-transfer-encoding; bh=qd6q1KnpRnn62gEDHflY/dA0RxTEnsQI8Xs5eAh5ATg=; b=mhZbNcl8636H+jDtwCcHcJ+POkEA22cMDT2YbqQHE25b5xavsDtj7NX2LsAMU7Fa1W Cw2MKJGDpioWup0Rz/5VvyGDBj7c7FhAD8cHLoaswbBaOkHg5CKUnu0FajTY/lNZj9r5 8QPAABadBJwBg/qtGzv7Urp05+MQgXyTiGWN+LSCrZk0REVuZ43pT0hQ3ay8OT3U7Lp5 usCY0GlrfX9Ddosle6nHHWR69p18idVzMRpjQUYYARict5PJGQt5Ph5AUmb62ScSJiwT 7qgdcKxHDs1UHOp64tJuunFLaxCT53vnUsQh/Qg6v7PWZiPcQjtd7rSJ4uph9MjQw5Qo Oydg== X-Gm-Message-State: ALoCoQl1TOjpTMNlEN/DCB4sH1q80pxGIzeL3vFNwH5arB3mPjxUdTvn+hBe98pVmZfMX+T0QLGw9SYz0Eeo8cd0MJUhqH3CSA== X-Received: by 10.140.216.20 with SMTP id m20mr18764236qhb.90.1452917760256; Fri, 15 Jan 2016 20:16:00 -0800 (PST) Received: from Andrews-MacBook-Pro.local.ahyatt-laptop (cpe-74-73-128-199.nyc.res.rr.com. [74.73.128.199]) by smtp.gmail.com with ESMTPSA id j23sm5796888qge.23.2016.01.15.20.15.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jan 2016 20:15:59 -0800 (PST) From: Andrew Hyatt To: Eli Zaretskii Subject: Re: bug#2530: 23/NS: redraws according to mouse-face are slow References: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com> <87d4aowc1l.fsf@cyd.mit.edu> <2E6E5869-2F70-4AF5-A917-7EA863D6BD42@gmail.com> <1ACB40A8-4422-4B9A-A0F7-FE0B9C738299@gmail.com> <87ab5rvds7.fsf@cyd.mit.edu> <48600A00-7FAE-4B80-8B3D-6615230918AF@gmail.com> <87r3hjrgc7.fsf@motte.fritz.box> <837fjbgumi.fsf@gnu.org> Date: Fri, 15 Jan 2016 23:15:58 -0500 In-Reply-To: <837fjbgumi.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 15 Jan 2016 09:38:29 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 2530 Cc: 2530@debbugs.gnu.org, ian@digg.com, Christian Kruse , david.reitter@gmail.com, cyd@stupidchicken.com, emacs-devel@gnu.org, adrian.b.robert@gmail.com 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: -0.7 (/) It seems there is some agreement that there isn't a serious problem anymore. I'll close these bugs as doneunreproducible. Flickerings or slowness in elisp should probably be considered a different, separate bug. Eli Zaretskii writes: >> From: Christian Kruse >> Date: Thu, 14 Jan 2016 22:39:20 +0100 >> Cc: 2530@debbugs.gnu.org, Chong Yidong , >> Adrian Robert , >> Ian Eure , Emacs-Devel devel >>=20 >> Compared to Linux (the Linux hardware is slower, a Notebook from 2011 >> and the OS X notebook is a Macbook Pro Retina from 2014), the OS X >> version is *pretty* slow. While everything I do with Emacs is nearly >> instant when using Linux there is a notably delay when using Emacs with >> OS X. > > That's normal: GNU/Linux is significantly more efficient than other > modern OSes. Nothing related to Emacs, really. > >> The worst example is Magit, which I already profiled because it is >> *so* slow: when using Linux `magit-status` shows up instantly. It takes >> about 1.5 seconds when using OS X (hold it, I am aware that this is not >> the place to discuss Magit performance, it is just an example :-) Every >> buffer with lots of lines (e.g. a notmuch buffer with 26k mails, my >> archive of the pg-hackers list) is lightning fast when using Linux, but >> takes round about 30 seconds when using OS X. > > Sounds like you describe a situation that is file I/O extensive. If > so, again, there's little wonder you see much faster operation on > GNU/Linux. If you'd say the same about comparison with MS-Windows, > say, then it would be something worth investigating. > >> Although I=E2=80=99m not sure that it is only the rendering engine (of c= ourse it >> could also be the elisp interpreter being slower) it occurs to me that >> it plays its part: especially redraw actions seem to be very slow. For >> example mu4e is unbearable slow when displaying maildirs with a lot of >> mails (e.g. the 26k mails maildir I mentioned above) but works fine for >> small mailboxes; and while the content of the maildir is loading, the >> buffer is flickering all the time as if it gets redrawn all the time. > > The flickering you describe can only be triggered by > platform-independent parts of the display engine, so again, this isn't > OS X or NS specific, AFAIU. > > Emacs comes with a trace-redisplay command (compiled only if you > configure Emacs --enable-testing=3D'yes,glyphs'), so if someone wants to > test the hypothesis that such flickering is specific to NS, they could > run the same scenario on OS X and on another system, after invoking > trace-redisplay, and compare the outputs. I'd expect them to be > identical (except for the addresses it prints). From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 15 23:21:03 2016 Received: (at control) by debbugs.gnu.org; 16 Jan 2016 04:21:03 +0000 Received: from localhost ([127.0.0.1]:50350 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aKIMJ-0000l4-7e for submit@debbugs.gnu.org; Fri, 15 Jan 2016 23:21:03 -0500 Received: from mail-qk0-f174.google.com ([209.85.220.174]:36317) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aKIMI-0000kI-5O for control@debbugs.gnu.org; Fri, 15 Jan 2016 23:21:02 -0500 Received: by mail-qk0-f174.google.com with SMTP id b66so1271291qkf.3 for ; Fri, 15 Jan 2016 20:21:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:message-id:to:from:subject; bh=3odxIgo9ric1Ro/EGS0oNLNNwOulwRRkCp/PbG/XR9Y=; b=CvwcnUJ14yX9EOIdxR9001Fw517tQxDWedYofNZ7J+LTrH+YbbWP0Nab1jOqTzgIrx SuWCG50m7wqCGrYj+Nm/qZ9o74GY9dBm3LGDoj2w1evj5AS7z5A740G0T8wX+yUpoda+ iwTmbMDckqh9ez6KbJOcESXKODMUyeN73Ni8O7+myLbTO6lvnAkxZatpivy7PHerrq7N FIpQzXz0oXWCwGy4VadFwzlXlH/BbK5uVCZCKHgdA8jtQ9cZskNEYRXVYuhVAYhyXMSy mHkWTg1ZDs8y/G9rv9zhZ7zSJbbz85SENoXnk4KqeKmyNchx0+Z4VgJAcCzlZRA00wGj hZ6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:message-id:to:from:subject; bh=3odxIgo9ric1Ro/EGS0oNLNNwOulwRRkCp/PbG/XR9Y=; b=ltRAVaDOz1VKJiynHIImIVH9830KGCKQkjHt5MwuWKsthRlRFTOl1GqNuylLJG6iGA /Nn5JiXvEQVNwBa0Op6tH7FIoD998l+YVwqQZ1Bguf9sxpGCGH489+vPesRQGwD3AtDD +O7ASymmbZ7nxm3pttSfXSjPP3D/PGmCKnoOXIpjwiEEIqLErUilVCiN40v5nMP+Pglq eQWgRghNyh5KqfPveaIPEswi+mpISyBFaRFC8E8SlJHdMMA2Blg6cMz1VxA68vSI5gFW b6DAx2qwSH4/XwncUlWTXFWiQcLFJjMYTHPTxmzkQd8SpAnOBV5+v1I9PaczxumkltY6 tIEg== X-Gm-Message-State: ALoCoQm9aT1AD3ghW/j3Cqi6zdnMDPD1GLl2D6Jy/G6D2ISPU0gtIkE5bL6VdNlOOWZdHGhZTibEjmFUiU0jmAbtjo7N7xg/gQ== X-Received: by 10.55.80.9 with SMTP id e9mr17102156qkb.94.1452918056918; Fri, 15 Jan 2016 20:20:56 -0800 (PST) Received: from Andrews-MacBook-Pro.local.ahyatt-laptop (cpe-74-73-128-199.nyc.res.rr.com. [74.73.128.199]) by smtp.gmail.com with ESMTPSA id d6sm5827730qkb.13.2016.01.15.20.20.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jan 2016 20:20:56 -0800 (PST) Date: Fri, 15 Jan 2016 23:20:55 -0500 Message-Id: To: control@debbugs.gnu.org From: Andrew Hyatt Subject: control message for bug #2530 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: control 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: -0.7 (/) tags 2530 unreproducible close 2530 From unknown Sun Aug 17 09:08:43 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 13 Feb 2016 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator