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 19:13:00 +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> <83wqc279sh.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 1403889269 3396 80.91.229.3 (27 Jun 2014 17:14:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Jun 2014 17:14: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 Fri Jun 27 19:14: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 1X0Zj7-0002nP-55 for geb-bug-gnu-emacs@m.gmane.org; Fri, 27 Jun 2014 19:14:17 +0200 Original-Received: from localhost ([::1]:51602 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0Zj6-0007rx-Nb for geb-bug-gnu-emacs@m.gmane.org; Fri, 27 Jun 2014 13:14:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40989) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0Ziy-0007q0-Rn for bug-gnu-emacs@gnu.org; Fri, 27 Jun 2014 13:14:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X0Zit-0001xP-7L for bug-gnu-emacs@gnu.org; Fri, 27 Jun 2014 13:14:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44055) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0Zit-0001x9-4i for bug-gnu-emacs@gnu.org; Fri, 27 Jun 2014 13:14:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1X0Zis-0004tC-Hw for bug-gnu-emacs@gnu.org; Fri, 27 Jun 2014 13:14: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: Fri, 27 Jun 2014 17:14: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.140388919218700 (code B ref 17124); Fri, 27 Jun 2014 17:14:02 +0000 Original-Received: (at 17124) by debbugs.gnu.org; 27 Jun 2014 17:13:12 +0000 Original-Received: from localhost ([127.0.0.1]:35205 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X0Zi3-0004rX-QN for submit@debbugs.gnu.org; Fri, 27 Jun 2014 13:13:12 -0400 Original-Received: from mailfe05.swip.net ([212.247.154.129]:34439 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X0Zi0-0004rA-JM for 17124@debbugs.gnu.org; Fri, 27 Jun 2014 13:13:10 -0400 X-T2-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00 Original-Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe05.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 508167476; Fri, 27 Jun 2014 19:13:01 +0200 In-Reply-To: <83wqc279sh.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:90900 Archived-At: Hello. 27 jun 2014 kl. 15:37 skrev Eli Zaretskii : >> From: Jan Dj=E4rv >> Date: Fri, 27 Jun 2014 12:44:58 +0200 >> Cc: Eli Zaretskii , >> 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? The "shake the divider" case becomes much worse, lots of flickering and = incomplete text. Wheter it prevents the slow redraws in real usage is hard to tell. It = is not easily reproduced in normal Emacs usage. >=20 >> 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. >=20 > 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. Basically yes. >=20 > 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. Yes. >=20 > 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. The toolkits I know of can handle invalidating different regions. > 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. 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. If the user is shaking the divider faster than we can draw, we = should toss intermediate steps. That is, if redisplay has to = recalculate all matrices before they have been drawn on the screen, so = be it. In this case I suspect it does help. When redisplay says "this region = needs to redraw", the backend (NS) tells Cocoa, "this region needs to = redraw". Cocoa then calls our code to say "please redraw this region". = I assume Cocoa does not call our draw function faster than it can = handle, i.e. it is called when the previous drawing is on screen. I don't know if Cocoa actually does this, it is pure speculation. >=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 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. >> 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. >=20 > Isn't this a problem that might make the entire idea unworkable? 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. Jan D.