From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Tick Reduction Date: Fri, 19 Nov 2021 21:50:39 +0200 Message-ID: <83y25judps.fsf@gnu.org> References: <87bl2hyzca.fsf@gnus.org> <835ysoursn.fsf@gnu.org> <831r3cugcp.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21674"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 19 20:52:31 2021 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 1mo9vy-0005Nu-Ji for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Nov 2021 20:52:30 +0100 Original-Received: from localhost ([::1]:38624 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mo9vx-0005Ne-Ad for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Nov 2021 14:52:29 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37402) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mo9uC-0004JH-N4 for emacs-devel@gnu.org; Fri, 19 Nov 2021 14:50:44 -0500 Original-Received: from [2001:470:142:3::e] (port=53022 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mo9uB-00015T-BP; Fri, 19 Nov 2021 14:50:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=aSqiCx0vvfufBLcISzjagwXkr2DhwJkYuFTs65lI0tc=; b=dUetyT/un1+E 9EWXpImTMKfdJ+mrX18zmrGlJ7Mk9Or2DnK8suMXNuXnwQByc0uJCb1Vzq/IkWcOPA4Lh9ZxTnFbj KIM57aHwYxE9kYie34EYErjRsvzfzCsmJ4XWG+Qg8vV4kWnT4bE8JYymBlLaim3anJzepEAf9N4vI 8iGyoEXmrLKaqmunGyMErL5NZn2JPksvmGEEAhurYx/R8jLiR4GeXIgPnqpG14nVhbGSL7oquxPW1 oHsArQGtd5LEyucT0JcMvi8JcpH0FVuv1pc0lSMyrd41k056lh8Sm0Jk4x+3rjdQkUKcHWkOsbDy5 A1eWNFxNT9oU2iec92K9KQ==; Original-Received: from [87.69.77.57] (port=4316 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mo9uB-00014i-0Y; Fri, 19 Nov 2021 14:50:39 -0500 In-Reply-To: (message from Stefan Monnier on Fri, 19 Nov 2021 14:24:46 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:279772 Archived-At: > From: Stefan Monnier > Cc: larsi@gnus.org, emacs-devel@gnu.org > Date: Fri, 19 Nov 2021 14:24:46 -0500 > > > That is only true when the window is redisplayed in its entirety, top > > to bottom. This happens relatively rarely, because the display engine > > tries very hard not to redisplay much more than absolutely necessary. > > These redisplay optimizations are generally structure as follows: > > > > . find the beginning and the end of the part of the buffer that needs > > to be redisplayed > > . redisplay that part starting at its beginning and going to its end > > > > This could result in redisplaying just one line, for example, or all > > lines between N and M. Which means that redisplay of a window can > > start at some arbitrary point in the middle of the window, without > > knowing anything about the preceding lines, except that they weren't > > changed on the glass. > > IIUC this isn't quite true: the "old" glyph matrix still contains the > rendering result of the previous lines and while it's old, it's still > up-to-date, so we might be able to extract the alignment info we need > from that. The display code only assumes the current glyph matrix is up-to-date if a set of very conservative tests succeeds. In the other cases, it doesn't use the contents of the current glyph matrix. And if this is not enough, let me remind you that the display engine also includes a set of functions that "emulate" redisplay, and those cannot use the glyph matrices at all, because they many times are used for text that is not displayed at all. > >> so I think we could handle the case of "align > >> with some previous line" (with some non-trivial caveats since it means > >> that future changes in that previous line would need to cause POS to be > >> re-processed, which may require disabling some optimizations). > > What you want would require every redisplay to always redraw the > > entire window. IOW, disable _all_ redisplay optimizations. > > Not necessarily always: we could record dependencies between lines of > the glyph matrix such that we only grow the set of redisplayed lines > when it's actually needed (i.e. when the corresponding text does use > such cross-line alignment). Anything can be implemented: this is software, after all. All I'm saying is that it won't be easy, not at all. And once again, the display code tries very hard not to use the current glyph matrix because there's no good way of knowing when it's up to date, especially when you are in the middle of some Lisp code.