From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Newsgroups: gmane.emacs.bugs Subject: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs Date: Fri, 27 Jun 2014 12:44:58 +0200 Message-ID: References: <3720C794-D850-4F7A-B5C4-1BC1A72BA26B@gmail.com> <83a9cayekp.fsf@gnu.org> <7D2257F7-2E81-44C8-9DC7-6A837BF43DAB@gmail.com> <837g7efcc4.fsf@gnu.org> <83d2h1ccsp.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1403865984 32150 80.91.229.3 (27 Jun 2014 10:46:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Jun 2014 10:46:24 +0000 (UTC) Cc: 17124@debbugs.gnu.org To: Eric Froemling Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 27 12:46:18 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X0Tfe-0006Zk-40 for geb-bug-gnu-emacs@m.gmane.org; Fri, 27 Jun 2014 12:46:18 +0200 Original-Received: from localhost ([::1]:49255 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0Tfc-0008Gt-Vr for geb-bug-gnu-emacs@m.gmane.org; Fri, 27 Jun 2014 06:46:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34487) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0TfU-0008FR-97 for bug-gnu-emacs@gnu.org; Fri, 27 Jun 2014 06:46:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X0TfO-0003t6-Jj for bug-gnu-emacs@gnu.org; Fri, 27 Jun 2014 06:46:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43210) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0TfO-0003t2-H2 for bug-gnu-emacs@gnu.org; Fri, 27 Jun 2014 06:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1X0TfN-00084e-SM for bug-gnu-emacs@gnu.org; Fri, 27 Jun 2014 06:46:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 27 Jun 2014 10:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17124 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 17124-submit@debbugs.gnu.org id=B17124.140386591330947 (code B ref 17124); Fri, 27 Jun 2014 10:46:01 +0000 Original-Received: (at 17124) by debbugs.gnu.org; 27 Jun 2014 10:45:13 +0000 Original-Received: from localhost ([127.0.0.1]:34360 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X0Tea-000834-Hd for submit@debbugs.gnu.org; Fri, 27 Jun 2014 06:45:13 -0400 Original-Received: from mailfe04.swip.net ([212.247.154.97]:51862 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X0TeV-000829-SN for 17124@debbugs.gnu.org; Fri, 27 Jun 2014 06:45:09 -0400 X-T2-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_40 Original-Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe04.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 510930833; Fri, 27 Jun 2014 12:44:59 +0200 In-Reply-To: X-Mailer: Apple Mail (2.1878.2) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:90893 Archived-At: Hello. 1 apr 2014 kl. 18:57 skrev Eric Froemling : >=20 > On Apr 1, 2014, at 8:03 AM, Eli Zaretskii wrote: >=20 >>> From: Eric Froemling >>> Date: Mon, 31 Mar 2014 22:23:33 -0700 >>> Cc: 17124@debbugs.gnu.org >>>=20 >>> Ok here=92s some further info/possible repro case if it is of use: >>> I built my own emacs by doing a bzr branch = bzr://bzr.sv.gnu.org/emacs/trunk, >>> then autogen.sh and ./configure =97with-ns >>> I removed my .emacs file so as to get default settings, then = launched emacs, >>> opened a large text file, and subdivided the frame into several = windows. >>> With this setup it is quite easy for me to get the slowdown to = happen by just >>> dragging a divider around for a bit. >>> Here=92s a clip of a slowdown with the activity monitor visible: >>> https://www.youtube.com/watch?v=3DolkyqVOWSLs >>> You can see that emacs is only using a few percent cpu throughout = the slow redraw, >>> whatever that may imply. >>=20 >> If Emacs does not use too much CPU cycles, it's probably not an Emacs >> problem. >=20 It actually is. Emacs draws too much, and the backing store gets = swamped with requests. See = https://developer.apple.com/library/mac/documentation/Performance/Conceptu= al/Drawing/Articles/FlushingContent.html and https://developer.apple.com/library/mac/technotes/tn2133/_index.html With the "shake the divider" recepie (see below), redisplay_internal is = called more than 30 times per second. On an old computer (end of 2008) = I get about 37 times per second. But each redisplay results in multiple draw_begin/end, so for drawing, = it is more than 37 times per second. What we would need is for redisplay to be more in line with what = toolkits does w.r.t. drawing. First calculate all glyphs, but don't do any drawing. Then invalidate those regions that needs redraw (a new RIF function), = and let the backends deside when it is appropriate to draw by calling a = redisplay function that does the actual drawing, based on the latest = glyphs. This was suggested here: http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg00821.html with some further discussion about here: http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00433.html I think there is room for optimizations in the generic display also, for = example moving the mouse redraws the entire mode line, even if the mouse = pointer is outside the frame. >>=20 >>> I=92ve also attached a sample I took of emacs during such a = slowdown. >>> It looks like a lot of calls are blocking in = _CGSSynchronizeWindowBackingStore >>> under the hood. >>=20 >> I don't know how to read that. Are the numbers there CPU times, or >> are they numbers of calls to each function? If the latter, then they >> are not very useful in this case. >=20 > You can see the total samples per thread broken up down into the call = chain. > ..so in the main thread the time seems to be somewhat evenly divided = between > draw_glyphs, draw_window_fringes, etc, all of which seem to be = blocking > in _CGSSynchronizeWindowBackingStore. >=20 > Can anyone try to repro this? (basically open a large buffer, = subdivide a > frame into quite a few windows, and then vigorously shake a horizontal > divider for a bit. In my case I usually get a slow refresh after 5-15 = seconds). > It can happen in other cases too such as window resizes but this seems > to be the easiest way to trigger it. > I=92m using a pretty vanilla OSX Mavericks install on a retina MBP; = curious > if others are seeing this.. >=20 It is easy to trigger by shaking the divider. I can sort of fix this by replacing some flushWindow with = setNeedsDisplay:YES. This has the drawback that updating the frame while shaking the divider = becomes slower, and sometimes stops updating the frame at all until I = stop moving the mouse. Jan D.