From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs Date: Mon, 30 Jun 2014 17:45:35 +0300 Message-ID: <838uoe5ucw.fsf@gnu.org> 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> <044D6949-2D7F-4C78-AE24-55C8885DDFCC@swipnet.se> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1404139586 3491 80.91.229.3 (30 Jun 2014 14:46:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 30 Jun 2014 14:46:26 +0000 (UTC) Cc: ericfroemling@gmail.com, 17124@debbugs.gnu.org To: Jan =?UTF-8?Q?Dj=C3=A4rv?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 30 16:46: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 1X1cqX-0008Rx-Gk for geb-bug-gnu-emacs@m.gmane.org; Mon, 30 Jun 2014 16:46:17 +0200 Original-Received: from localhost ([::1]:34800 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1cqX-0001Q3-6S for geb-bug-gnu-emacs@m.gmane.org; Mon, 30 Jun 2014 10:46:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45425) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1cqO-0001O0-BX for bug-gnu-emacs@gnu.org; Mon, 30 Jun 2014 10:46:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X1cqI-0006HG-Hj for bug-gnu-emacs@gnu.org; Mon, 30 Jun 2014 10:46:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46879) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1cqI-0006HB-E5 for bug-gnu-emacs@gnu.org; Mon, 30 Jun 2014 10:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1X1cqI-0001G6-4Z for bug-gnu-emacs@gnu.org; Mon, 30 Jun 2014 10:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Jun 2014 14: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.14041395574822 (code B ref 17124); Mon, 30 Jun 2014 14:46:01 +0000 Original-Received: (at 17124) by debbugs.gnu.org; 30 Jun 2014 14:45:57 +0000 Original-Received: from localhost ([127.0.0.1]:38029 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X1cq9-0001Ff-C2 for submit@debbugs.gnu.org; Mon, 30 Jun 2014 10:45:57 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:39121) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X1cq3-0001FL-J5 for 17124@debbugs.gnu.org; Mon, 30 Jun 2014 10:45:51 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0N7Z00500L04J300@mtaout29.012.net.il> for 17124@debbugs.gnu.org; Mon, 30 Jun 2014 17:45:44 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N7Z005HKL081V00@mtaout29.012.net.il>; Mon, 30 Jun 2014 17:45:44 +0300 (IDT) In-reply-to: <044D6949-2D7F-4C78-AE24-55C8885DDFCC@swipnet.se> X-012-Sender: halo1@inter.net.il 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:91004 Archived-At: > From: Jan Djärv > Date: Mon, 30 Jun 2014 14:55:22 +0200 > Cc: ericfroemling@gmail.com, > 17124@debbugs.gnu.org > > >>> Does it help to set redisplay-dont-pause to nil? > >> > >> The "shake the divider" case becomes much worse, lots of flickering and incomplete text. > > > > But do you see less drawing requests sent to the backend? > > No. Strange. When this variable is nil, redisplay should abandon its job when it sees that some input is pending. > > 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. I'd expect one such block for every window that is affected by the divider move. If you see more, there's something else at work here. > The Emacs way is really only ment for small updates outside the event loop. Most of the updates are indeed small. > >> 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. > > > > 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. So the redraws of the mode line when mouse is moved no longer happen on the trunk? If so, this is a good improvement. > 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. Thanks.