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: Scrolling commands and skipping redisplay, was: Re: emacs rendering comparisson between emacs23 and emacs26.3 Date: Tue, 21 Apr 2020 17:02:07 +0300 Message-ID: <83mu75ey3k.fsf@gnu.org> References: <20200403174757.GA8266@ACM> <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> <478c2aab-a5fc-61c2-02e2-2d9846b95273@yandex.ru> <83v9m9nltx.fsf@gnu.org> <83tv1rn8fx.fsf@gnu.org> <4f8bb277-b376-97bf-8539-799688d8e66d@yandex.ru> <83eesvmj15.fsf@gnu.org> <6eec7f68-770e-b3b1-4627-6222f3ef7216@yandex.ru> <83ftd9kwlu.fsf@gnu.org> <1de9d24f-eeb7-7d0a-3768-4baba4365066@yandex.ru> <83zhbcdmyi.fsf@gnu.org> <61f565cd-4fee-d48c-a9ef-b78419b3d058@yandex.ru> <83wo6ed4kb.fsf@gnu.org> <464b5639-7790-fdbc-b519-22a6b0e8c016@yandex.ru> <83o8rqaucp.fsf@gnu.org> <83lfmqgpb9.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="46323"; 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 21 16:03:33 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 1jQtUq-000BwJ-Vu for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Apr 2020 16:03:32 +0200 Original-Received: from localhost ([::1]:58864 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQtUq-000881-4x for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Apr 2020 10:03:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56188) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQtU1-0007Lz-F3 for emacs-devel@gnu.org; Tue, 21 Apr 2020 10:02:42 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41880) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQtTz-0006kJ-Hk; Tue, 21 Apr 2020 10:02:39 -0400 Original-Received: from [176.228.60.248] (port=4928 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jQtTn-0002uv-U6; Tue, 21 Apr 2020 10:02:28 -0400 In-Reply-To: (message from Dmitry Gutov on Tue, 21 Apr 2020 04:27:19 +0300) 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:247466 Archived-At: > Cc: acm@muc.de, rudalics@gmx.at, rrandresf@gmail.com, rms@gnu.org, > emacs-devel@gnu.org > From: Dmitry Gutov > Date: Tue, 21 Apr 2020 04:27:19 +0300 > > On 20.04.2020 18:16, Eli Zaretskii wrote: > > >> As we've determined, certain commands force redisplay to be performed > >> anyway (though partially). > > > > That's not redisplay, that's JIT fontification that happens as side > > effect of redisplay. It can _also_ happen as side effect of other > > commands. But that's not redisplay. > > A certain amount of work that's also part of redisplay. I suggest to use a common terminology, otherwise we will just confuse each other. Let's agree to call "redisplay" only what happens when Emacs calls one of the two functions: redisplay_internal and echo_area_display. OK? Redisplay calls many functions, including fontification-functions, but those functions themselves are not to be called "redisplay", because they don't display anything. > IIRC posn-at-point also "simulates redisplay". Not sure if scrolling > commands use it, but others do. Many commands do, much more than what you mentioned. If we call all of them "redisplay" we will completely muddy the waters. > I'm saying this because my current impression is still that redisplay is > skipped sometimes (when Emacs is busy) for performance reasons. Only if input is available (or if it arrives during redisplay, assuming you set redisplay-dont-pause to a nil value). > > It already > > attempts to reuse every piece of display that can be kept. For > > example, if you type C-n on the bottom-most screen line, and you have > > scroll-conservatively set, the display engine will redraw exactly one > > screen line, and all the rest will be scrolled (via a direct Xlib > > call) on the glass, without regenerating the glyphs. > > That's an interesting tidbit. But it seems to also say that redisplay > for C-n is usually quite fast. It is fast. By default, it will scroll half the window and redraw the other half (due to recentering). > > You will see in redisplay_window and its subroutines a lot of code > > that attempts to do exactly that: figure out what has changed and what > > hasn't. You are in effect saying that this must be radically > > improved, in which case I'd happily agree, but please believe me that > > it is not a trivial job, certainly not if you want to stay within the > > current design of the display engine. You will probably need to > > design and implement various new fields of the window and buffer > > objects that will cache more data about the previous state of buffer > > and display than what they already do, make sure these caches are > > reset when no longer valid, then build new redisplay optimizations > > based on those, find the conditions where the optimizations can and > > cannot be used, etc. > > So I wouldn't be correct to say that the display is only dependent on > the current window configuration (shown buffers, window sizes, window > scroll positions), buffer text which can be checked via > buffer-modified-tick and the overlays which... might have a similar > "counter" added? I don't think I understand the question, but the display engine already uses the buffer-modified-tick and overlay-modified tick. > But mode-lines and header-lines aren't amenable to caching, right? That > complicates things. Header line is almost never a problem, it hardly ever changes IME. Mode line, OTOH, changes almost all the time (at least with its default format), so I think caching it would be quite futile. And you will anyway need to somehow compare the cached value with the updated one, something that the display engine already does, using the results of the previous display as "the cache".