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 16:09:44 -0500 Message-ID: References: <87bl2hyzca.fsf@gnus.org> <835ysoursn.fsf@gnu.org> <831r3cugcp.fsf@gnu.org> <83y25judps.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="38262"; 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 22:11:09 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 1moBA2-0009hM-Jw for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Nov 2021 22:11:06 +0100 Original-Received: from localhost ([::1]:57370 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1moBA1-0006zg-81 for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Nov 2021 16:11:05 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60198) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1moB8x-0006EP-5x for emacs-devel@gnu.org; Fri, 19 Nov 2021 16:09:59 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:25411) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1moB8u-0003Ml-6R; Fri, 19 Nov 2021 16:09:58 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3534F80582; Fri, 19 Nov 2021 16:09:54 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 52CFE8044E; Fri, 19 Nov 2021 16:09:45 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1637356185; bh=sY/INNCjcFzawie4MV+974I0QNHKLkjBiHA/DGv1WF0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=UJukdAsuC5WI9HTgZdIRIe76nyyIv4iwK5yHZAEyfm7XY51yqAbW8B3njWEVIeKmh yr/+YXYopTazB3VoKmRRpRngLCa7Dwu2+AVcv0XmMYOmMeJMjKjQCZqc9loFxQksHm qNAYYo1wwcsenPd8B05/cml4o1dKivZg93mp81e+KdVw+MhR4q8jYEx6P5My9iDoWM Fze69qmecqGw68hVUmScbElJ3oqRBK6BlpihW1gGmt533S6KbPAgU2UhEpGB7apHx6 cbdp4zPQF4gIKVLXR07WigX0mUKGYFPEnVIR5rHcgYahJxGsLIq9DBU4wMHHfj+2f7 YhcDuOJq9/dTA== Original-Received: from pastel (unknown [216.154.30.173]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id F31BF120728; Fri, 19 Nov 2021 16:09:44 -0500 (EST) In-Reply-To: <83y25judps.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 19 Nov 2021 21:50:39 +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:279773 Archived-At: >> 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. So far it indeed doesn't use the old glyph matrix, but that matrix is still around and (for the lines that preceded the currently processed text) should still be up-to-date. So we could conceivably use that. > 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. Yes, we may have to declare that for functions that "emulate" the redisplay internally, the resulting horizontal position info might not always be quite right (might not reflect what you'll see on the glass) for text tat uses the new alignment functionality :-( >> 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. No doubt. I'm just trying to separate "hard" from "fundamentally incompatible". AFAICT it could be made to work without having to rewrite all the code, so I consider it as "not fundamentally incompatible". But I agree it wouldn't be easy. > 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. Indeed, it might imply a rethink of how we manage the old/current/desired glyph matrices. Stefan