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.bugs Subject: bug#75291: Redisplay not updating fringe when face filter changes Date: Thu, 02 Jan 2025 22:56:57 +0200 Message-ID: <86h66hhr3a.fsf@gnu.org> References: <874j2h3yzb.fsf@dancol.org> <8634i1jeai.fsf@gnu.org> <87ttah2hcd.fsf@dancol.org> <86v7uxhv9c.fsf@gnu.org> <87ikqx2dwh.fsf@dancol.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29914"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 75291@debbugs.gnu.org, mina86@mina86.com To: Daniel Colascione Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 02 21:58:25 2025 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1tTSGu-0007ew-OX for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Jan 2025 21:58:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTSGh-0006jm-81; Thu, 02 Jan 2025 15:58:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tTSGY-0006gl-Vm for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 15:58:04 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tTSGY-0007hP-La for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 15:58:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=8LKDkuLHOqNJyT2Rh/xvEYbpifl62zLvHQ9nL9Zh5C4=; b=jhzXKsoIc7cetVlzg84vVcuAzxHyg7Acob19snSRZ2jO01Y7G06Pk4IBl6ggBtr5n4KKCYUNxZupXdxDbjlcQ1A95OcvsALX0WtakkKRxXmv2wKdubvfU7bBsC/IZeNrE0RzKWE5zRD+SJjD+0n/obrUY6QzHDcSD4y8nrn29Au5IqHxVhaBJ0nZRxOu3NlnAFkkWIApWshSu7dZUTHRnunta/aJDOK08MLpsH0Siufuqr/7lPLQidUjerZlXLk7ALVmcOIFGg/Bwx/w5uEtOQeDhlb/xyNuf0QWmZfGeBbsuzSbBXxqGOdJH1vHImOZTUTwW1rIaXRpher+1cX8PQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tTSGY-0008Nd-6P for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 15:58:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Jan 2025 20:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75291 X-GNU-PR-Package: emacs Original-Received: via spool by 75291-submit@debbugs.gnu.org id=B75291.173585143132109 (code B ref 75291); Thu, 02 Jan 2025 20:58:02 +0000 Original-Received: (at 75291) by debbugs.gnu.org; 2 Jan 2025 20:57:11 +0000 Original-Received: from localhost ([127.0.0.1]:46921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTSFi-0008Lp-NI for submit@debbugs.gnu.org; Thu, 02 Jan 2025 15:57:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41882) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tTSFg-0008LV-7v for 75291@debbugs.gnu.org; Thu, 02 Jan 2025 15:57:09 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tTSFZ-0007eH-0s; Thu, 02 Jan 2025 15:57:01 -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=8LKDkuLHOqNJyT2Rh/xvEYbpifl62zLvHQ9nL9Zh5C4=; b=IcT2xNAg9plU n24qNf4g0oe32JPj07RHPaXapIM5J+Gvfwn9IBb+lZWm7RV944vN68/x34DkW4hWXDm6Xgn8ZZAT2 6fzf1W14mPJ3sWy4IaYfQnb5oexzleeiDACZv816YFSNXW1fPrWJlEXsw4hSZhjegTTOMMpEm8O/W 0O8NnwqS2j8z99JXJAfAGununB7GDJuIEqjCADlf6E9I2beZ7SBdmjTT1B6g8VSpeNAALgMgt0p69 KE9hi6c996CZOkp1J3Ik8s1OCzyqqsYzyPjnl6eT8iM4rUwyUrGBcHz+g4VUSB6bYgSraxFu1i5HT 5TkidgaxLcSga5alVXC73A==; In-Reply-To: <87ikqx2dwh.fsf@dancol.org> (message from Daniel Colascione on Thu, 02 Jan 2025 14:50:54 -0500) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:298238 Archived-At: > From: Daniel Colascione > Cc: 75291@debbugs.gnu.org, mina86@mina86.com > Date: Thu, 02 Jan 2025 14:50:54 -0500 > > Eli Zaretskii writes: > > > Yes, redrawing everything will work, but will also cause flicker, and > > is generally expensive, thus undesirable. > > FWIW, it doesn't seem to cause flicker in practice. I see flicker only > when walking through messages in mu4e --- we do redisplay and draw only > the background, and I haven't figured out why yet. But in general, on a > modern window system, turning a given redisplay into a full redisplay > shouldn't cause flicker, even if it's inefficient. I think it depends on whether you use double-buffering (some people don't or cannot) and whether you have the mouse pointer over an Emacs frame. Also, depending on the GUI toolkit, the decorations might flicker. > I came across overlay_arrows_changed_p --- isn't this function trying to > deal with exactly the case of something in the fringe changing outside > the changed text region? So you want to add to display_line code that sets each glyph_row's redraw_fringe_bitmaps_p flag when the fringe face changes? That could probably work, provided that we disable redisplay optimizations which might avoid calling display_line (you will see that we already disable such optimizations when overlay_arrows_changed_p returns non-zero). We might actually need to disable more of the optimizations, because the overlay-arrow thing doesn't contradict the optimizations that scroll the pixels, something that reaction to changes in the fringe face cannot tolerate. > > Regarding your idea about Lisp function that would invalidate GUI > > parts: it is not very easy, since a Lisp program cannot easily know > > where on the screen a given region of buffer positions will be. > > There is posn-at-point, of course, but (a) it is quite expensive, and > > (b) when Lisp runs, display could be outdated, so what posn-at-point > > returns could be inaccurate. > > I was imagining a lisp function that would make the next redisplay of a > window do what you suggest in the next paragraph. What does Lisp know about the fringe face that the display engine doesn't? > I'm not sure we'd even need an explicit Lisp function though. > Face filters with :window are defined to compare window parameter values > with eq, so couldn't we keep track of all the :filtered face > specifications we encounter during face resolution and have > set-window-parameter check whether the parameter it's setting is on the > list of possible face filters and, if so, force next redisplay to > evaluate faces? set-window-parameter wouldn't even have to do a deep > comparison, because it's just eq. First, the fringe face might not be window-specific (by default, it isn't). So I'm not sure how a window parameter will help. face-remapping-alist is per-buffer, not per-window. Next, the main problem with faces is face inheritance and face merging (the latter is not relevant to fringe, I think). Given that some attribute of some face changes, how do you know whether such a change causes the fringe face to change? We'd probably need to realize it anew, and then compare to the cached one? And we'd need to do that for each window, because of face-remapping-alist? > > The way to "notice the change in the face" is not a simple problem to > > solve, btw. We currently don't know which faces change when some face > > is modified. So we have a frame-global flag that is set when any face > > changes its attributes. If we use that flag for detecting potential > > changes in the fringe face, we'd start redrawing fringes > > unnecessarily. > > How many unnecessary face recalculations would we do? ISTM we could make > the invalidation pretty precise as long as we're just looking at > window parameters. See above. I think the proof of the proverbial pudding is in eating: maybe doing the above will produce reasonable performance.