From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3 Date: Tue, 07 Apr 2020 17:26:25 +0300 Message-ID: <83imibqsmm.fsf@gnu.org> References: <20200403174757.GA8266@ACM> <20200404104553.GA5329@ACM> <07fe3b69-3ab2-3173-0696-cb17809e2b91@gmx.at> <83blo7v68b.fsf@gnu.org> <1845d7aa-9ae4-3d95-6a30-c7b1d8d8adec@gmx.at> <83a73qt6zs.fsf@gnu.org> <97c4254e-ff43-8402-3645-f713c408c245@gmx.at> <83y2r9syby.fsf@gnu.org> <20200405195753.GG5049@ACM> <542b48ba-4dfa-820f-ba50-4b147ab6d8e2@yandex.ru> <0a5f70aa-4985-8f8d-81d6-6ac4a60a94f9@yandex.ru> <838sj8sphk.fsf@gnu.org> <834ktwsmfw.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="57822"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, rrandresf@gmail.com, emacs-devel@gnu.org, rms@gnu.org, rudalics@gmx.at To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 07 16:28:48 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jLpDa-000Ept-UR for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Apr 2020 16:28:47 +0200 Original-Received: from localhost ([::1]:48254 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLpDZ-0004pT-T0 for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Apr 2020 10:28:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55055) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLpBV-00009t-3U for emacs-devel@gnu.org; Tue, 07 Apr 2020 10:26:38 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57905) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jLpBU-0006pU-C7; Tue, 07 Apr 2020 10:26:36 -0400 Original-Received: from [176.228.60.248] (port=3706 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jLpBM-0002EK-IX; Tue, 07 Apr 2020 10:26:29 -0400 In-Reply-To: (message from Dmitry Gutov on Mon, 6 Apr 2020 20:16:43 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:246605 Archived-At: > Cc: acm@muc.de, rudalics@gmx.at, rrandresf@gmail.com, rms@gnu.org, > emacs-devel@gnu.org > From: Dmitry Gutov > Date: Mon, 6 Apr 2020 20:16:43 +0300 > > > What that binding does is affect the portions of display code that are > > run as part of window_scroll_pixel_based, which the scroll command > > calls to calculate a suitable position of window-start by simulating > > display. That display code runs with fontifications disabled, which > > makes it faster. > > > > All the scroll commands in Emacs do is more or less calculate the > > window-start point; the rest is done when redisplay kicks in. > > So what happens then? Does it trigger jit-lock anyway? Basically, yes. But with a twist, see below. > If so, I don't understand how we get the apparent performance improvement from using fast-but-imprecise-scrolling. To explain that, I need to step back and describe how jit-lock mechanism works, from the display engine POV, and then how the scroll commands work. (See also a large commentary in keyboard.c around line 250.) For simplicity, let's assume we have a buffer with no overlays, no display strings, and no other complications, only faces. Let's also assume the text is entirely L2R, so we can ignore what bidi.c does. When the display engine starts working on displaying a window, it begins from the window-start position, loads all the faces and other display-related stuff, then starts layout by moving one character at a time in the direction of increasing buffer positions, and computing the metrics of each character as determined by the face(s) at each position. It stops when it gets to a buffer position where the 'fontified' text property changes its value. If the new value of 'fontified' is nil, the display engine calls fontification-functions. jit-lock adds its function to that hook, so jit-lock is called. What jit-lock does, in a nutshell, is call the current buffer's fontification function(s) on a chunk of text starting at the position for which it was called, and it puts on that chunk a value of t for the 'fontified' text property. (Where that chunk ended is the position where the 'fontified' property's value will again change to nil, and if that position is inside the window, jit-lock will be called again when the display engine gets to that position.) After fontification-functions return, the display engine processes the faces in the chunk that has been fontified; then it continues marching through the buffer. Next, I need to describe how scroll commands work. Assuming you typed C-v, the scroll command computes the new window-start point. It does so by beginning at the current window-start, then moving through the buffer text until it reaches the point that is N pixels down, where N is the height of the window. To move through the text, the scroll command uses functions from the display engine that "simulate" display, i.e. they perform the same layout calculations, but don't prepare anything to be sent to the glass. However -- and this is the important part -- this "display simulation" uses the same code described above that looks for positions where the 'fontified' property is nil and calls fontification-functions to fontify such text. This is necessary, because fontification can change the metrics of the text on display, and so any pixel-wise calculations and decisions whether given text is or isn't inside a window must be sure the text is fontified and has the right faces in order to produce accurate results. When the scroll command is done computing the new window-start point, it sets a special flag telling redisplay to obey that window-start value (otherwise redisplay might decide to compute window-start on its own), and returns. Then redisplay kicks in, and does its thing described above. It will find the entire text until the new window-start already fontified, and also some text after the new window-start (because jit-lock works in chunks, and usually fontifies slightly more than strictly needed). So displaying the new contents of the window will need to fontify only those parts visible in the window that were not already fontified when the scroll command looked for the new window-start. If you lean on C-v, then the scroll command is repeatedly called to find the next window-start, and repeatedly fontifies the text it goes through. If you scroll N screen-fulls, the fontification of the first N-1 screen-fulls (if they were never displayed before, which happens when you visit a file and immediately start scrolling) is "wasted effort" for the purposes of the final window redisplay, because those N-1 screen-fulls will not be displayed. Only the fontification of the last screen-full is "useful", because it saves some, sometimes all, of the fontification job of the stuff to be eventually displayed when you stop scrolling. Enter fast-but-imprecise-scrolling. What it does is disable jit-lock during the part where the scroll command walked the buffer to find the next window-start position. Crucially, it also disables putting the non-nil 'fontified' property on the text traversed by the scroll command (because that is done by jit-lock). So when you stop scrolling, redisplay of the stuff that ends up in the window will have to fontify all of what is visible in the window. Bottom line: fast-but-imprecise-scrolling saves the work of jit-lock when scrolling more than one screen-full, and is more-or-less useless when scrolling one screen-full. IOW, it is a "solution" for the use case of leaning on C-v or M-v to scroll far into the buffer that was never before displayed. Of course, if fast-but-imprecise-scrolling makes the job of scroll commands so much easier that Emacs is capable of keeping up with the keyboard auto-repeat rate, then every screen-full you scroll through _will_ be displayed, and therefore will be fontified by the calls to jit-lock from redisplay itself -- and that will again make scrolling slower. So fast-but-imprecise-scrolling is most efficient when it makes scroll commands faster, but not too fast... Sorry for the long email, I hope this tricky issue is now at least a tad more clear.