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: Fri, 27 Jun 2014 16:37:50 +0300 Message-ID: <83wqc279sh.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> 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 1403876367 31812 80.91.229.3 (27 Jun 2014 13:39:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Jun 2014 13:39:27 +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 Fri Jun 27 15:39: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 1X0WN5-0003Bk-JR for geb-bug-gnu-emacs@m.gmane.org; Fri, 27 Jun 2014 15:39:19 +0200 Original-Received: from localhost ([::1]:50429 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0WN5-0005hY-4i for geb-bug-gnu-emacs@m.gmane.org; Fri, 27 Jun 2014 09:39:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48087) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0WMv-0005gU-Rb for bug-gnu-emacs@gnu.org; Fri, 27 Jun 2014 09:39:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X0WMo-0002qi-PJ for bug-gnu-emacs@gnu.org; Fri, 27 Jun 2014 09:39:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43250) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0WMo-0002qE-Fv for bug-gnu-emacs@gnu.org; Fri, 27 Jun 2014 09:39:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1X0WMo-0006IF-0Z for bug-gnu-emacs@gnu.org; Fri, 27 Jun 2014 09:39: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: Fri, 27 Jun 2014 13:39: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.140387629624100 (code B ref 17124); Fri, 27 Jun 2014 13:39:01 +0000 Original-Received: (at 17124) by debbugs.gnu.org; 27 Jun 2014 13:38:16 +0000 Original-Received: from localhost ([127.0.0.1]:34400 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X0WM2-0006Gd-Vj for submit@debbugs.gnu.org; Fri, 27 Jun 2014 09:38:15 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:46894) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X0WLz-0006GK-6v for 17124@debbugs.gnu.org; Fri, 27 Jun 2014 09:38:12 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N7T00100XI63H00@a-mtaout20.012.net.il> for 17124@debbugs.gnu.org; Fri, 27 Jun 2014 16:38:03 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N7T000ILXVFY650@a-mtaout20.012.net.il>; Fri, 27 Jun 2014 16:38:03 +0300 (IDT) In-reply-to: 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:90895 Archived-At: > From: Jan Djärv > Date: Fri, 27 Jun 2014 12:44:58 +0200 > Cc: Eli Zaretskii , > 17124@debbugs.gnu.org > > 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. Does it help to set redisplay-dont-pause to nil? > 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. We already have the first stage of that in place: that's redisplay_windows, which is called for each frame that needs to be redisplayed. What you are suggesting is to make update_frame, which currently redraws the frame's windows based on what redisplay_windows calculated, to instead just mark the areas which need redrawing as dirty. That sounds easy enough, but the problem is that we might need more display updates until the backend decides that it is a good time to actually redraw. E.g., the user might type some commands in the meantime. AFAIU, what you are saying is let all these changes affect only the glyph matrices that redisplay_windows calculates, so that when the backend wants to redraw, the Emacs function that actually redraws will see the up-to-date glyph matrices and use them. This could work if the backend can accumulate durty regions incrementally. IOW, if it gets 2 requests for areas that partially overlap, will it mark the union of those areas as dirty? If not, we will need serious changes to how redisplay_windows and its subroutines work, because they currently assume the previous full redisplay cycle updated everything on the glass, and don't keep record of the glyph matrices beyond the last redisplay. 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. > 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. 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. > 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. Isn't this a problem that might make the entire idea unworkable?