From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eric Froemling Newsgroups: gmane.emacs.bugs Subject: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs Date: Tue, 1 Apr 2014 09:57:03 -0700 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.2 \(1874\)) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1396371504 2617 80.91.229.3 (1 Apr 2014 16:58:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Apr 2014 16:58:24 +0000 (UTC) Cc: 17124@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 01 18:58:19 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 1WV20u-0001Ob-MU for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Apr 2014 18:58:16 +0200 Original-Received: from localhost ([::1]:33282 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WV20u-0002dt-DZ for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Apr 2014 12:58:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36317) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WV20m-0002Zv-Om for bug-gnu-emacs@gnu.org; Tue, 01 Apr 2014 12:58:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WV20h-0003Dr-3i for bug-gnu-emacs@gnu.org; Tue, 01 Apr 2014 12:58:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58430) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WV20h-0003Dh-0e for bug-gnu-emacs@gnu.org; Tue, 01 Apr 2014 12:58:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WV20g-00059U-C5 for bug-gnu-emacs@gnu.org; Tue, 01 Apr 2014 12:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eric Froemling Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Apr 2014 16:58:02 +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.139637143019738 (code B ref 17124); Tue, 01 Apr 2014 16:58:02 +0000 Original-Received: (at 17124) by debbugs.gnu.org; 1 Apr 2014 16:57:10 +0000 Original-Received: from localhost ([127.0.0.1]:59612 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WV1zq-00058H-4o for submit@debbugs.gnu.org; Tue, 01 Apr 2014 12:57:10 -0400 Original-Received: from mail-pd0-f170.google.com ([209.85.192.170]:58147) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WV1zn-000586-83 for 17124@debbugs.gnu.org; Tue, 01 Apr 2014 12:57:08 -0400 Original-Received: by mail-pd0-f170.google.com with SMTP id v10so9890056pde.1 for <17124@debbugs.gnu.org>; Tue, 01 Apr 2014 09:57:06 -0700 (PDT) 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=BhH7cLdJMfNuG4/uANJCOBa8nQ1kJzhS2jAuA6Wf5f0=; b=OeefmPOUgF00MFaLW9f+uIbm9ju7N9zYpo8cdAMv7sKl3dCLpP6yZc4nwPX81EhhgC 4pUGd6/XfE688XxUnxtQ7hIMvq8yLelWWAbnB0hyZS/BjjMdEKDB5/rMiF8KRoyIfTiz DBNniXB6KrxGeqTS96epgEHOo2w46NrYV45CTkM806tC309HjxElEOzUR6TQf08nvJ3L xXB7pwwF4Q4FUqpat69cdjOxxvXPCPAdZvO2oU6JMma2OoKW9+GXxBaTxzoxULOmfFRk gducsWLUu3H7kuhCoaTfiCpN0qk9MNHNo7RtbMhM+P1wf6wxvdC/2GVGHyv4vYQTJCJb zKVg== X-Received: by 10.66.142.132 with SMTP id rw4mr32626048pab.6.1396371425972; Tue, 01 Apr 2014 09:57:05 -0700 (PDT) Original-Received: from [10.0.1.16] (c-69-181-20-108.hsd1.ca.comcast.net. [69.181.20.108]) by mx.google.com with ESMTPSA id ac5sm51093832pbc.37.2014.04.01.09.57.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Apr 2014 09:57:05 -0700 (PDT) In-Reply-To: <83d2h1ccsp.fsf@gnu.org> X-Mailer: Apple Mail (2.1874) 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:87601 Archived-At: On Apr 1, 2014, at 8:03 AM, Eli Zaretskii wrote: >> 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 >> 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. 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. 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 > Thanks.