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: Mon, 30 Jun 2014 14:55:22 +0200 Message-ID: <044D6949-2D7F-4C78-AE24-55C8885DDFCC@swipnet.se> 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> <83wqc279sh.fsf@gnu.org> <83r42a6s7w.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 1404132989 5191 80.91.229.3 (30 Jun 2014 12:56:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 30 Jun 2014 12:56:29 +0000 (UTC) Cc: ericfroemling@gmail.com, 17124@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 30 14:56:22 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 1X1b89-0003OJ-CT for geb-bug-gnu-emacs@m.gmane.org; Mon, 30 Jun 2014 14:56:21 +0200 Original-Received: from localhost ([::1]:34149 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1b88-00085H-Lf for geb-bug-gnu-emacs@m.gmane.org; Mon, 30 Jun 2014 08:56:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45883) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1b7z-00082f-CJ for bug-gnu-emacs@gnu.org; Mon, 30 Jun 2014 08:56:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X1b7r-0000tj-Hb for bug-gnu-emacs@gnu.org; Mon, 30 Jun 2014 08:56:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46361) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1b7r-0000tX-4M for bug-gnu-emacs@gnu.org; Mon, 30 Jun 2014 08:56:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1X1b7q-0005gN-FF for bug-gnu-emacs@gnu.org; Mon, 30 Jun 2014 08:56:02 -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: Mon, 30 Jun 2014 12:56: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.140413294221814 (code B ref 17124); Mon, 30 Jun 2014 12:56:02 +0000 Original-Received: (at 17124) by debbugs.gnu.org; 30 Jun 2014 12:55:42 +0000 Original-Received: from localhost ([127.0.0.1]:37511 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X1b7S-0005fh-8K for submit@debbugs.gnu.org; Mon, 30 Jun 2014 08:55:42 -0400 Original-Received: from mailfe02.swip.net ([212.247.154.33]:36519 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X1b7K-0005fI-No for 17124@debbugs.gnu.org; Mon, 30 Jun 2014 08:55:35 -0400 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Original-Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe02.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 513796333; Mon, 30 Jun 2014 14:55:23 +0200 In-Reply-To: <83r42a6s7w.fsf@gnu.org> 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:90999 Archived-At: 27 jun 2014 kl. 21:57 skrev Eli Zaretskii : >> From: Jan Dj=E4rv >> Date: Fri, 27 Jun 2014 19:13:00 +0200 >> Cc: ericfroemling@gmail.com, >> 17124@debbugs.gnu.org >>=20 >>>> 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. >>>=20 >>> Does it help to set redisplay-dont-pause to nil? >>=20 >> The "shake the divider" case becomes much worse, lots of flickering = and incomplete text. >=20 > But do you see less drawing requests sent to the backend? No. >=20 >>> Incidentally, I don't think your suggestion will help in the "shake >>> the divider" scenario: when window dimensions are changed, we toss = the >>> glyph matrices of the affected windows, and then allocate them anew >>> (and perform a thorough redisplay of those windows). So this will >>> anyhow require to redisplay the entire window completely, and the >>> backend will not be able to save us any redraws. >>=20 >> Not by itself, but if the backend is responsible for when actual = drawing happens we can make sure we don't draw faster than the screen = can update. >=20 > I actually find it hard to believe that we overwhelm the backend, > except, maybe, when the X client is on a remote machine. E.g., on > Windows the "shake the divider" recipe doesn't show any signs of a > problem, and the CPU load is never more than a single execution unit > being busy, which means not much is at work except Emacs itself. With > today's multi-core fast machines, how come it's impossible to redraw a > region 37 times a second? Well, the actual number is more than 37. 37 is the number of times = redisplay is called. But within one redisplay, there is a couple of separate update_begin/end = blocks. There was a couple of extra redraws happening in the NS port, but after = removing them, I can still see problems with shake the divider. It all goes away if drawing is done the normal way, i.e. from the event = handler. Maybe OSX is optimized for that case, as it covers about every = application except Emacs. The Emacs way is really only ment for small updates outside the event = loop. >=20 >>>> 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 >>> Please show the recipe to reproduce this. I just tried a naive way = of >>> doing that, and didn't see any mode-line updates even when the mouse >>> is inside the frame. So I must be missing something. >>>=20 >>=20 >> I had problems seeing what was drawn and when so I added debug code = to see what the font driver actually draws. But I see now that it is = different for X11. So it might be NS specific. What can make the = modeline redraw in one version of Emacs and not in another? I thought = all that was generic code. >=20 > It _is_ generic code. Perhaps we are not talking about the same > things: when you say that the mode line is redrawn, what exactly do > you see? I see the mode line redrawn by inspecting what strings are sent to the = font backend. Actually the whole buffer is redrawn, I was just looking = at an empty buffer. But these are the extra redrawn I mentioned above, = they are gone in trunk now. >=20 >> Well, shake the divider is not really something normal a user does. = It is just a way to force the issue. But slow redraws happens in normal = usage also, i.e. switching buffers and editing. It solves the second = case, but makes shake the divider worse in terms of smooth redraws. >=20 > We need to compare the performance with this proposed feature with the > current implementation. I think it's hard to talk about this without > some measurements, and probably also some reasonably important use > cases (which "shake the divider" isn't, IMO). With the extra redrawns gone, shake the divider performes rather well = now if I force draws to the event loop. There is the occational pause = in redraw, but I guess that is expected. But I can't do this all in the backend, the downside is that there are = double redraws. One for the redisplay call and one from the event loop = when the redisplay is done. Also, the event loop redraw redraws the = whole frame. If I get some time I'll try to make a test. Jan D.