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#74537: [PATCH] An on-disk image modification does a cache miss Date: Tue, 26 Nov 2024 15:31:50 +0200 Message-ID: <86plmiglyx.fsf@gnu.org> References: <87ed2z6m7q.fsf@ledu-giraud.fr> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20513"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 74537@debbugs.gnu.org To: Manuel Giraud Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 26 14:32:31 2024 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 1tFvg7-0005Ao-9X for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 Nov 2024 14:32:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tFvfr-0002Z4-6R; Tue, 26 Nov 2024 08:32:16 -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 1tFvfh-0002YU-QG for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2024 08:32:07 -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 1tFvfe-0007Vr-Ul for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2024 08:32:03 -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=fvogOwNDR2JJ40f26CAhsO7/hL39RZ0SnbYBOukyxP8=; b=Y/8iahtxxknSTMDpystiPOfCrB8O2AOWw4jocAG4jWbh++w/+iTXW8s3quehhq+fdcpMgBNbQBo9n0Fp06+Qxu6ojco6H2WxjjytKWpmm1qIKne/2fLGPpE3W62HfoZIh+MiZLGLZ4YXmIU6k8g1QntIUe45Z3PAAcBs7zAiQW6dn8Wn+eWqFMLWLJJywfdT6jnANCGb1AWZxN8zixjVpvngYqCUS/HcHqdM3yV+KZBNYlQlcdlEXD9gtbstQw2A1bv8+jI1zmV06G+dFkNNY3cTYCVFVOp8/rvPV87CXCBY7V07Pj6N/uRWdRvmwTCo5Br1rhAyBP0UKVCsNdawFw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tFvfe-0002Ql-R9 for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2024 08:32: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: Tue, 26 Nov 2024 13:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74537 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 74537-submit@debbugs.gnu.org id=B74537.17326279229337 (code B ref 74537); Tue, 26 Nov 2024 13:32:02 +0000 Original-Received: (at 74537) by debbugs.gnu.org; 26 Nov 2024 13:32:02 +0000 Original-Received: from localhost ([127.0.0.1]:48173 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFvfd-0002QO-WD for submit@debbugs.gnu.org; Tue, 26 Nov 2024 08:32:02 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35644) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFvfc-0002Q4-5z for 74537@debbugs.gnu.org; Tue, 26 Nov 2024 08:32:00 -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 1tFvfW-0007Tz-C0; Tue, 26 Nov 2024 08:31:54 -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=fvogOwNDR2JJ40f26CAhsO7/hL39RZ0SnbYBOukyxP8=; b=IGAsH5YUsH3Y zGgcuQ1Zb9jVXrhFzb3ps/YTVxbTbInOL7sl1CyCOcFk2FQw1NhlkLxH35wbOzlwHBEsSOClM0t09 6LNSlf7T7iV71Ub+DjObrdF3FRW2Kb+TU2YSFj7CYVEW67vxM5ZWfaR2iSNeO+3xc95LB8xiaSZH/ T0OgR38JqalFBknj6haIDgvntiP7ixjySKY79wmZVXnqZQrqGRyJZOsjuYOJ7+WPrttAnEQz2eL5H oO6Ysu2y3q0BOr9vOtv1/Fa9wQshhrk3AS1AqB2DrKyVbz7kekXIiWaaYpmodDn9sJcU240pBfE7l mXJQJvzPTw9rzvmwnCE+7g==; In-Reply-To: <87ed2z6m7q.fsf@ledu-giraud.fr> (bug-gnu-emacs@gnu.org) 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:295987 Archived-At: > Date: Mon, 25 Nov 2024 22:24:25 +0100 > From: Manuel Giraud via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > With this patch, when an image file is modified on disk, the associated > cache image is invalidated and re-read from disk. Thanks, but I'm not sure it's a good idea to do that automatically whenever lookup_image is called. First, lookup_image is called only when we need to create or access an image with only its Lisp descriptor in hand; once the image has been displayed, that should happen relatively rarely. For example, the glyph matrices used to manipulate the display record only the image's cached ID, and the code accesses the cached image without calling lookup_image. So this change could have weird confusing effects, whereby the fact that the image was modified on disk becomes apparent only after some display-related actions, but not after others. For example, scrolling a window by a small amount will not notice the change on disk, whereas significant changes, especially when the image goes off the window and back into it, will show the change. Don't you see such issues if you install the change? Second, if the image is already on display, and the file changes on disk, some layout calculations could see different dimensions than what is actually on display, which will cause subtle bugs. For example, what if there's a 'display' property such as this: '(space :width (0.5 (image PROPS))) and an image with those same PROPS is already shown on display? The code which implements the above calls lookup_image, which will simulate a cache miss if the file has changed, and will then load the new file, which could return dimensions different from the image already on display. So the width of the space glyph produced by the above will be different from that of the displayed image, and we could have misalignment until the next redisplay which redraws the image. So I think this should probably be controlled by a variable visible from Lisp, by default off, and we might also have a function to invalidate all the cached images whose files have changed (which will then need to trigger a thorough redisplay, I think).