From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Aborting display. Is this possible? Date: Mon, 20 Oct 2014 22:24:54 +0300 Message-ID: <83lhoabl2x.fsf@gnu.org> References: <20141019141712.GB3197@acm.acm> <83lhoccdv7.fsf@gnu.org> <20141019154255.GC3197@acm.acm> <83egu4c4om.fsf@gnu.org> <20141020110949.GA2947@acm.acm> <8338aidbcq.fsf@gnu.org> <20141020185757.GD2947@acm.acm> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1413833139 9147 80.91.229.3 (20 Oct 2014 19:25:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Oct 2014 19:25:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 20 21:25:32 2014 Return-path: Envelope-to: ged-emacs-devel@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 1XgIa9-0000kR-IL for ged-emacs-devel@m.gmane.org; Mon, 20 Oct 2014 21:25:29 +0200 Original-Received: from localhost ([::1]:46480 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgIa8-0000EV-SM for ged-emacs-devel@m.gmane.org; Mon, 20 Oct 2014 15:25:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51209) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgIZq-0000D2-LZ for emacs-devel@gnu.org; Mon, 20 Oct 2014 15:25:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XgIZl-0008EF-FD for emacs-devel@gnu.org; Mon, 20 Oct 2014 15:25:10 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:45584) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgIZl-00089t-1v for emacs-devel@gnu.org; Mon, 20 Oct 2014 15:25:05 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NDR00J00CCG5X00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Mon, 20 Oct 2014 22:25:03 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDR00IOICLQYX40@a-mtaout22.012.net.il>; Mon, 20 Oct 2014 22:25:03 +0300 (IDT) In-reply-to: <20141020185757.GD2947@acm.acm> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:175609 Archived-At: > Date: Mon, 20 Oct 2014 18:57:57 +0000 > From: Alan Mackenzie > Cc: emacs-devel@gnu.org > > On a PageDown, Emacs needs to do font-locking just to work out how far > awy the next page is, like David said. There is a comment in > window_scroll_line_based: "Fvertical_motion enters redisplay, which can > trigger fontification...". This is the killer: scrolling a screen of > xdisp.c is taking, on average, ~0.09s, the bulk of this time being > fontification, whereas the key events are coming in every ~0.03s. > Some way has to be found to scroll with only every third screen (at most) > getting font-locked. window_scroll_line_based is not relevant to GUI frames, only to text-mode frames. And window_scroll_pixel_based does not call vertical-motion. Also, "enters redisplay" needs to be taken with a grain of salt here. The reference is to display "simulation", whereby Emacs proceeds through buffer text line after line, computing the metrics of the characters as it goes (and invoking fontification functions if needed), but doesn't store the results in glyph matrices and doesn't proceed to redrawing based on that. So it's only partial redisplay. The full redisplay will be done later, after the scrolling command did its part, and Emacs is back in the command loop with no available input. > If every glyph were assumed to be the same size, the calculation of the > window-start position for the current scroll operation would be _much_ > faster: display would still have to account for text lines overflowing > screen lines, and invisible text, and so on, Yes, but we've lost that paradise when we introduced variable-font support in Emacs 21. > So, how about the following strategy: when the (new) variable > `face-instead-of-fontifying' is bound to a face, AND the input queue is > non-empty (or, perhaps, very non-empty), the appropriate subroutine of > window-scroll should deem characters without a `face' (or `fontified' ?) > property to have face `face-instead-of-fontifying'. > > This should empty the input queue pretty quickly, enabling a current > buffer portion to get displayed frequently enough. This would mean we will sometimes wind up in the wrong place after scroll. IOW, you are sacrificing correctness on behalf of some (questionable for now) speedup. I say ""questionable" because it's not clear to me that using just one fixed face will significantly speed up the process of painstakingly moving through text line by line. > But in the default situation (redisplay-dont-pause is non-nil), once the > calculation of the glyph matrix has begun, the redrawing necessarily > takes place. Yes, once. After that, if input events come in faster than Emacs can process them, you again get a frozen outdated window. There isn't really a good solution for when input comes in faster than Emacs can process it. > > Then the same will happen again for the next PageDown key. The result > > is a frozen window display, because all the attempts to redisplay are > > aborted due to input rate that is high enough to preempt redisplay, > > but not high enough to prevent Emacs from entering redisplay after > > every (or almost every) PageDown key. To see more frequent updates > > that give an illusion of scrolling, we would need a feature that > > ignores the input availability, or maybe dynamically changes the > > number of input events that could be ignored when redisplay falls > > behind. We don't have such a feature. > > Is this really the case? Is it not that the font-locking caused by > scrolling is slow enough, that the input queue is never empty, hence > redisplay doesn't get a look in? It eventually gets to that, because some screenfuls need more time to redisplay. > > Now, what happens when you release the key? The input queue is still > > full of unprocessed PageDown keys. As I explained above, Emacs will > > drain the entire input queue before it enters redisplay; thus the long > > delay you see after releasing the key. > > And each such PageDown key will necessitate full font-locking for its > never-to-be-displayed screen. No, not full, only partial. See above. > > You want Emacs to "immediately" display the new buffer position, but > > this is impossible without some code that would quickly scan the input > > queue, analyze what's there, and "understand" that 100 PageDown > > keystrokes can be "optimized" by executing a single scroll-up-command > > with a suitable argument. IOW, we would need some input preprocessing > > stage that could "optimize" input by replacing a series of commands > > with a single command, and do that cheaply. We don't have such a > > feature; patches to add it will probably be welcome. > > :-). If my analysis is right, this wouldn't help. A single mega-scroll > would still be font-locking the entire intermediate buffer region. Again, only partially so. And please note that scrolling is inherently at disadvantage here, because it tells Emacs to move N screen lines up/down, so Emacs must first figure out where that lands it. Other commands that move through buffer text, like goto-char, don't have that problem.