From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Tick Reduction Date: Fri, 19 Nov 2021 14:24:46 -0500 Message-ID: References: <87bl2hyzca.fsf@gnus.org> <835ysoursn.fsf@gnu.org> <831r3cugcp.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12970"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: larsi@gnus.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 19 20:27:53 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 1mo9Y9-000384-HO for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Nov 2021 20:27:53 +0100 Original-Received: from localhost ([::1]:49278 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mo9Y7-0000Zp-J7 for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Nov 2021 14:27:51 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55822) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mo9WK-0008Cl-Sf for emacs-devel@gnu.org; Fri, 19 Nov 2021 14:26:00 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18063) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mo9WG-0004Hg-Ln; Fri, 19 Nov 2021 14:25:58 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3F0301001C2; Fri, 19 Nov 2021 14:25:54 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 74E9B10016E; Fri, 19 Nov 2021 14:25:52 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1637349952; bh=C22OpU7lqPu0TGR8QXcQmbfDIOwkZ7K8SoVDladQKhY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=kKZMf8dKs3sW0Bp7s1kCn4MBtQXtOYnsEb8poLo3JxwvwJUDcIhXdjpZrOEX17VxI g6Cx5lwb3sIKIOQABiwe2T9Sunl01T9OnUNcermouoDSXWP7TrlC+bJT61eyavUPG5 ujGF1gHFru1O7deHdYta667AhditdQfO0xlUM5lkelsd/oVS3vONNb/g9MUYaCq5i5 inuTIZQXhpjf8XcOc5QQsiweB/0MFuJAOZsyxC5VeeIzb6V4gNPJA1my3AQNFgc4kO XuZEbcnupubmqxk4Nv04V51Gl1WZ59DC2spcK+N4/KjEmD/klZY7+XnIFRQWn7ULWt n67XzSXG7hitg== Original-Received: from ceviche (modemcable085.122-83-70.mc.videotron.ca [70.83.122.85]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 51DEB1208A4; Fri, 19 Nov 2021 14:25:52 -0500 (EST) In-Reply-To: <831r3cugcp.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 19 Nov 2021 20:53:42 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:279771 Archived-At: > 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. >> 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). Stefan