From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Scrolling commands and skipping redisplay, was: Re: emacs rendering comparisson between emacs23 and emacs26.3 Date: Thu, 9 Apr 2020 03:32:13 +0300 Message-ID: <478c2aab-a5fc-61c2-02e2-2d9846b95273@yandex.ru> 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> <83imibqsmm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------384BC28B318666BB5C3108DF" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="28047"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 Cc: acm@muc.de, rrandresf@gmail.com, emacs-devel@gnu.org, rms@gnu.org, rudalics@gmx.at To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 09 02:32:57 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 1jML7o-00079C-RQ for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Apr 2020 02:32:56 +0200 Original-Received: from localhost ([::1]:41958 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jML7n-0002f9-SW for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Apr 2020 20:32:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35940) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jML7F-00024F-AM for emacs-devel@gnu.org; Wed, 08 Apr 2020 20:32:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jML7D-0002ZY-PU for emacs-devel@gnu.org; Wed, 08 Apr 2020 20:32:21 -0400 Original-Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:39077) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jML7D-0002Yu-GP; Wed, 08 Apr 2020 20:32:19 -0400 Original-Received: by mail-wr1-x430.google.com with SMTP id p10so9748738wrt.6; Wed, 08 Apr 2020 17:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=KfmkWIlH/9m8M9FQuUAuzrVyCC0mPBBECPIgXDXjGfw=; b=dpTQh8E4ZSE7TNIw5UFNC+9wHmf9ISZfwDChn9FBE4U68MV3xD0YnFXjLV6BC/LwYv iZLmDp/JjGrwzD7jtw0b11WAx+ejNAGLyhjDSqKdHwx0W/FQ5mbm0Sz3qPVmasdowJ1h +qzPa0r+klZ84h2I0GucZ7aEVAK6T+YMzh+J9+QVh6KHBdwtk0IC0nBHfPKahEqJjvlb wTzyZyw63p1mxjb0J6TdAhV0Vtv8up+litnkcfYDyPPEtskms6dInIlazXuN39h+7qPO IJ+4TOJfNEi5wSOp3uoPMLlscR8yTlQbmwxr9WW1hkMdaKa5ncHskY6zhEm35R/yufIN mChw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=KfmkWIlH/9m8M9FQuUAuzrVyCC0mPBBECPIgXDXjGfw=; b=ZoEEBmboBh7DwJ7fj2NfUl0va4bbykfqV3bd0RHgjYVnUaGc5r9RmCAgSFTBPOs8pU Lrh4UnxMTEbLVf647wMy8UkPdE5pNKNiuunr62+KyV6VbnKRIN1aYATzRtCJZ/cxmIih XqvXUETPAAIS45Go9nTNhDTYR+NzsxCHAWnZcDSe8RGg2HFGuvQfkS6hsLioiVngiaBs SUcoYltQnbqHZByCtLMYRLSYZVH5mcTdWKYrlT4GuNrBRrS9ZqYTL4n3S3ZytvLsyCW+ 2vhqEuqsnnBbnqgcP6uU63MLbNcvjIIlqkBPH+CP1eKJEl9FUNenFwjfaRpOjP/RETcn 0LEw== X-Gm-Message-State: AGi0PuYWc9ctCZr4FvayVh+OEGbGowJT6wvAxSb3uIHC9TWHVc7wkn1W sDwRunmFJn01QvX1X0C03KLmyb5456U= X-Google-Smtp-Source: APiQypIbSfe0F/jlAvO2M/e9K47hzbTHnuD8rc71w3q3jfMtpnCqxm7WStxe9moFAGr/VFFkV4gINA== X-Received: by 2002:adf:de82:: with SMTP id w2mr8754788wrl.169.1586392337322; Wed, 08 Apr 2020 17:32:17 -0700 (PDT) Original-Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id c190sm1537924wme.10.2020.04.08.17.32.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Apr 2020 17:32:16 -0700 (PDT) In-Reply-To: <83imibqsmm.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::430 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:246690 Archived-At: This is a multi-part message in MIME format. --------------384BC28B318666BB5C3108DF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Eli, On 07.04.2020 17:26, Eli Zaretskii wrote: >> 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.) <...> Thank you, what was a lot of additional detail. The overall approach seems well-considered, but maybe there are ways to make it more... predictable, so to speak. Or more helpful. > 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. As you noted, when fontification takes a considerable amount of time, redisplay should be "free", relatively speaking. And if we didn't skip it, it would provide the user with the feedback that something is indeed happening. > 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. The obvious downside here is that it's "imprecise". And that it doesn't really know whether redisplay is going to be skipped, even though it could take a pretty good guess (using the input_was_pending variable, for example). If the user has leaned on C-v, they are probably not looking for much precision. But they might want it if they just pressed C-v once. > 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... In my testing with an '-Og -g3' build (from emacs-27; master is much faster with the recent tweaks) it allows for redisplay once every several screenfuls or so. So it seems like a good tradeoff, in those particular conditions. I wonder if we could make it more coordinated. The two problems I see are: 1. Scrolling commands can skip jit-lock when redisplay is going to apply it (loss of precision for no actual perf improvement), or they don't skip it (when fast-but-... is nil) even though redisplay will (precision seems unimportant in most pending-input scenarios). 2. If we accumulate a large enough input queue of C-v keypresses, Emacs won't react to anything (even to C-g, even hit three times) until it processes these events. Even though the user most probably wanted it to stop scrolling just as soon as they stopped leaning on C-v. I think #2 can have good solutions, but I only have rough suggestions about that. But let's look at #1. We could fix the discrepancy in two ways: either skip jit-lock in window_scroll if and only if redisplay will likely be skipped (as shown in the attached patch) (a). Or never skip it there, as well as indicate to redisplay that it shouldn't be skipped either (b). (a) will increase reactivity, as well as make it harder to overwhelm the input queue, which will be perceived by a number of users (who manage to hit these conditions and have slow enough machines) as better responsiveness. (b) will let the user see what's happening instead, even though the scrolling will become slower. I think this is a plus in its own right, because scrolling is a visual activity; there's little point in doing it if you can't see where you scrolled to. We can probably implement this by setting input_was_pending unconditionally to false inside window_scroll. Logically, I think I'd prefer (b), especially if a solution for #2 was added as well. Because as soon as #2 is solved, (a)'s benefit isn't so clear anymore. But either (a) or (b), both look more responsive to me than the current state of affairs. --------------384BC28B318666BB5C3108DF Content-Type: text/x-patch; charset=UTF-8; name="fast_scroll_on_pending_input.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="fast_scroll_on_pending_input.diff" diff --git a/src/keyboard.c b/src/keyboard.c index bf1f5da22d..3ea8ba7619 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -281,7 +281,7 @@ #define GROW_RAW_KEYBUF \ with the input rate, but if it can keep up just enough that there's no input_pending when we begin the command, then redisplay is not skipped which results in better feedback to the user. */ -static bool input_was_pending; +bool input_was_pending; /* Circular buffer for pre-read keyboard input. */ diff --git a/src/window.c b/src/window.c index ff17cd88f3..5f7a08ec8c 100644 --- a/src/window.c +++ b/src/window.c @@ -5466,6 +5466,8 @@ window_internal_height (struct window *w) means don't signal an error if we try to move over BEGV or ZV, respectively. */ +extern bool input_was_pending; + static void window_scroll (Lisp_Object window, EMACS_INT n, bool whole, bool noerror) { @@ -5475,7 +5477,7 @@ window_scroll (Lisp_Object window, EMACS_INT n, bool whole, bool noerror) wset_redisplay (XWINDOW (window)); - if (whole && Vfast_but_imprecise_scrolling) + if (whole && input_was_pending) specbind (Qfontification_functions, Qnil); /* On GUI frames, use the pixel-based version which is much slower --------------384BC28B318666BB5C3108DF--