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#9218: 24.0.50; bidi-display-reordering slowdown Date: Tue, 02 Aug 2011 01:40:45 -0400 Message-ID: References: <877h6xx96g.fsf@sophokles.streitblatt.de> <83livdartq.fsf@gnu.org> <83k4axare8.fsf@gnu.org> <87bow9vsc9.fsf@sophokles.streitblatt.de> <83hb60c47f.fsf@gnu.org> <87aabsuash.fsf@sophokles.streitblatt.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1312263710 616 80.91.229.12 (2 Aug 2011 05:41:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 2 Aug 2011 05:41:50 +0000 (UTC) Cc: 9218@debbugs.gnu.org To: Florian Beck Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Aug 02 07:41:42 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Qo7jZ-0006DY-7Q for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Aug 2011 07:41:41 +0200 Original-Received: from localhost ([::1]:33939 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qo7jY-0006RG-QG for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Aug 2011 01:41:40 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:46390) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qo7jV-0006R0-Na for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2011 01:41:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qo7jU-0002CP-F8 for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2011 01:41:37 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50658) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qo7jU-0002CL-CB for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2011 01:41:36 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1Qo7jt-0003YE-Sz; Tue, 02 Aug 2011 01:42:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Aug 2011 05:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9218 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9218-submit@debbugs.gnu.org id=B9218.131226367513596 (code B ref 9218); Tue, 02 Aug 2011 05:42:01 +0000 Original-Received: (at 9218) by debbugs.gnu.org; 2 Aug 2011 05:41:15 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Qo7j8-0003XF-Hf for submit@debbugs.gnu.org; Tue, 02 Aug 2011 01:41:15 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Qo7j5-0003X6-C3 for 9218@debbugs.gnu.org; Tue, 02 Aug 2011 01:41:13 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Qo7if-0002FR-1c; Tue, 02 Aug 2011 01:40:45 -0400 In-reply-to: <87aabsuash.fsf@sophokles.streitblatt.de> (message from Florian Beck on Mon, 01 Aug 2011 22:38:54 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Tue, 02 Aug 2011 01:42:01 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) 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:49792 Archived-At: > From: Florian Beck > Cc: Florian Beck , 9218@debbugs.gnu.org > Date: Mon, 01 Aug 2011 22:38:54 +0200 > > Eli Zaretskii writes: > > >> From: Florian Beck > >> Cc: abstraktion@t-online.de, 9218@debbugs.gnu.org > >> Date: Mon, 01 Aug 2011 21:34:30 +0200 > >> > >> Eli Zaretskii writes: > >> > >> >> Does setting bidi-paragraph-direction to left-to-right solve the > >> >> problem? > >> > > >> > I meant without resetting bidi-display-reordering to nil, of course. > >> > >> The file opens just as fast as with bidi turned of, yes. Scrolling is > >> still somewhat erratic: scrolling down takes 12s the first time > > > > By "scrolling down" you mean all the way to the end, or just one > > screenful? > > `scroll-up-command' > > And `end-of-buffer' takes the same time (12s vs 1s). > > But it does not matter really. ANY command takes several seconds in that > buffer, e.g. C-h k or C-x C-b – whereas they are instantanious with > bidi turned off. And this slowdown happens only on the first command, as you said earlier? Or on subsequent commands as well? > In fact may even be slowed down because of fontification going on > (it only is slow the first time). Other commands are reproduciable. "Reproducible" meaning that they are slow not only the first time? Or does it mean something else? > Strange. C-h k is instantenious, but C-h k takes several seconds to > complete. Happens also when selecting the other window (*Help*) with the mouse or > when running C-h k in the other window. I'd expect the slowdown to happen whenever the window showing that Org buffer needs to be redisplayed. "C-h k" just displays the prompt in the echo area, so the Org window needs not be redisplayed. "C-h k " pops up another window, which changes the dimensions of the Org window, and that window needs to be redisplayed. Emacs tries very hard to optimize the redisplay, because redisplaying everything would be painfully slow. That is the reason of what you see, IIUC. > Once the large buffer is no longer displayed in any window, the speed > returns to normal (as in before bidi). Of course: a buffer not shown in any window does not affect redisplay in any way. > >> But that still requires me to set a per file variable. > > > > I think Org Mode should set bidi-paragraph-direction in all its > > buffers. Can you see any disadvantages to such a solution? > > Personally, no. People writing right-to-left prose might, though. Why would they? setting bidi-paragraph-direction does not disable reordering of R2L text, it just makes all Org entries start at the left margin. > I just don't understand why it has to be that slow. I have paragraphs of > reasonable length. Is it because of the folded display? Probably, but that's a guess, and I'm not very good at guessing when the display engine is involved. I don't suppose you can ship me that file for playing with it? If not, I will try to generate such a huge file and see if I get such slowdown. My Org files are much shorter (around 1.5K lines overall), and I don't see any slowdown at all, even though I have Flyspell mode turned on in them. > (But then there are only some 6000 visible lines which should be > fast in any case.) The display engine has no way of knowing which parts are visible and which aren't, until it actually traverses all of that text and takes notice of the `invisible' text properties, selective-display, and other display features. This is much slower than just scanning buffer text, and somehow the paragraph direction detection comes into play during this in a way that slows things down unbearably... > Org mode does quite a bit of fontification, i.e. it already parses > the buffer. Fontification pays attention only to a few text properties, while redisplay needs to cater to much more. > Is there a way for org mode to tell the display engine where a new > paragraph should be considered, what is to be displayed RtL or LtR, > etc? How can it do that without running the same code that the bidi display runs, and which is the cause of the slowdown? The rules of determining the paragraph direction are spelled out by an annex to the Unicode Standard (http://unicode.org/reports/tr9/#The_Paragraph_Level), and bidi.c includes its full implementation. Any piece of code that tries to do the same will be hit with the same slowness. IOW, to solve this problem without the need to set bidi-paragraph-direction non-nil, I need either (a) find a bug in the current bidi display that makes paragraph detection so slow in this case, or (b) find some way to optimize the paragraph detection so it runs faster or is invoked less in most cases like this one.