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: Mon, 20 Apr 2020 18:16:42 +0300 Message-ID: <83lfmqgpb9.fsf@gnu.org> References: <20200403174757.GA8266@ACM> <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> <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> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="91953"; 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 Mon Apr 20 17:18:21 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 1jQYBh-000NpO-Ir for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Apr 2020 17:18:21 +0200 Original-Received: from localhost ([::1]:37750 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQYBg-0002od-LE for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Apr 2020 11:18:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58268 helo=eggs1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQYAJ-0001Vq-HV for emacs-devel@gnu.org; Mon, 20 Apr 2020 11:16:56 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49148) by eggs1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQYAI-0002YB-Ew; Mon, 20 Apr 2020 11:16:54 -0400 Original-Received: from [176.228.60.248] (port=1468 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jQYAA-0006ZZ-5N; Mon, 20 Apr 2020 11:16:46 -0400 In-Reply-To: (message from Dmitry Gutov on Mon, 20 Apr 2020 06:27:17 +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:247393 Archived-At: > Cc: acm@muc.de, rudalics@gmx.at, rrandresf@gmail.com, rms@gnu.org, > emacs-devel@gnu.org > From: Dmitry Gutov > Date: Mon, 20 Apr 2020 06:27:17 +0300 > > >> To do that, need to modify the condition of skipping redisplay. > > > > Adding such a condition would be against Emacs design, which enters > > redisplay only when Emacs is idle. As long as Emacs is not idle, > > redisplay will be skipped, that's how Emacs is designed. > > 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. > If performing it in full in those cases will take just a little more CPU > time, the result might be Emacs that looks more responsive under load, > and just as fast. If you can find a way of reusing that information afterwards (more than redisplay itself already does), yes. But AFAIU you are talking about a thorough redesign of the Emacs display engine. 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. Of course, if you invoke a command that moves to a place that has no overlap with the text of the previous screenful, no such optimizations are possible, unless the new screen has some parts of it that happen to be identical to the old one (yes, Emacs does that optimization as well). > > Nothing else can be kept from the move_it_* phase, because the command > > that is running might not yet have finished, and so not all of the > > changes that affect display are known. > > It might be possible to construct some "cache key" that would allow us > to check whether the remainder of the command changed something that > would affect display. And if it didn't, use the last saved result of > move_it_*. 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. > >> But with that assumption, the extra condition of not skipping redisplay > >> could be simplified (?) to only checking whether the current screen has > >> been fontified already (i.e. 'fontified' is non-nil). If it's fontified, > >> we won't skip redisplay. > > > > I don't think forcing redisplay in the way that you suggest is a good > > idea, see above. > > Because... it will result in worse performance? No, because you will fight the design, and the design will fight back. That's all I can say. IMO, if we want to make the Emacs display more efficient, we need to redesign it.