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#74725: 31.0.50; image-scaling-factor is ignored by create-image Date: Sun, 08 Dec 2024 14:15:02 +0200 Message-ID: <86plm2fk1l.fsf@gnu.org> References: <2304cad6-884f-4528-a85e-ab9c06b80016@orange.fr> <868qsrim4a.fsf@gnu.org> <2793f551-8715-4679-8f52-b4673dd6802d@orange.fr> <86y10rh26m.fsf@gnu.org> <87plm3ghzw.fsf@yahoo.com> <86frmyhfss.fsf@gnu.org> <87h67eha9b.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24891"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 74725@debbugs.gnu.org, da_vid@orange.fr, alan@idiocy.org To: Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 08 13:16:24 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 1tKGD2-0006J0-8t for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 08 Dec 2024 13:16:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tKGCn-0007Lg-4M; Sun, 08 Dec 2024 07:16:09 -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 1tKGCi-0007LK-PY for bug-gnu-emacs@gnu.org; Sun, 08 Dec 2024 07:16: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 1tKGCh-0005ns-Cg for bug-gnu-emacs@gnu.org; Sun, 08 Dec 2024 07:16:04 -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=mzkQRG6KCv8kjtCq000W7laHzP7dCNuiEq1+7ZLlOdI=; b=v1bNxKkUmHKHPhxpk8oW88M8fzeFC2u/hra8yqUD4Xc9HfKQdTdSjQ45WNcL8ZoxGn+MAh86h8bgV1fRUooyzdt3wnd5PgSvwWelK/UrC+4JnAeHnhXnxdmSnPFqc3aKocO5WgpJmejGD30cxHQ1fLLCIX9fVlC1n9zjLF674omYZvrwIxc0kncCH7rzxUa+Bf7/tm07KDLHkCUCeUXzQZGHGXZTAVf8L71hRPsAnGWy3EYO88PzzTsxgUXPVYLfTV68QQuI+wX6JBx2sVrP/lGqfXv9kVETeJVkoRp674O++2whPqcyK5KZ3aZIidHEf6Rml7/xbcy3MbJY8ul1mw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tKGCg-00060e-8y for bug-gnu-emacs@gnu.org; Sun, 08 Dec 2024 07:16: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: Sun, 08 Dec 2024 12:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74725 X-GNU-PR-Package: emacs Original-Received: via spool by 74725-submit@debbugs.gnu.org id=B74725.173366012923033 (code B ref 74725); Sun, 08 Dec 2024 12:16:02 +0000 Original-Received: (at 74725) by debbugs.gnu.org; 8 Dec 2024 12:15:29 +0000 Original-Received: from localhost ([127.0.0.1]:49913 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKGC9-0005zR-59 for submit@debbugs.gnu.org; Sun, 08 Dec 2024 07:15:29 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:46088) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKGC6-0005z4-7e for 74725@debbugs.gnu.org; Sun, 08 Dec 2024 07:15:27 -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 1tKGBt-0005lp-Ed; Sun, 08 Dec 2024 07:15:14 -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=mzkQRG6KCv8kjtCq000W7laHzP7dCNuiEq1+7ZLlOdI=; b=r0YIZHXO7c+W CIEb/2wbCYyO3Nh2rL4ZpJTOASUfotBPbT/kViwf2VhRBuBDL6YCTV9nVM6n7X7+OB+4WZYB86Cxl EuTkZPDqDTHpXycDNT9A7u7npL9rLVPH73d/YQBf8mc0O58XJg5e73C32K32AJrJoZLXpPePigrfh LbpWKTP7167Oxti6PhkEb/WBkrea2PyUaRFiqNMMDmpjrvfl+qBYRr1NmGqqR8P1lesYTPaMM6G7L NDvjnhRGYiF81oypF17lKMyWR74Cqe8Z0AMUmrNGQby4+ormPyeBiZz5rwnrywBDq66TFr5QDv6qU TsGttHwop717p/FDuirs4w==; In-Reply-To: <87h67eha9b.fsf@yahoo.com> (message from Po Lu on Sun, 08 Dec 2024 16:03:28 +0800) 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:296633 Archived-At: > From: Po Lu > Cc: da_vid@orange.fr, alan@idiocy.org, 74725@debbugs.gnu.org > Date: Sun, 08 Dec 2024 16:03:28 +0800 > > Eli Zaretskii writes: > > >> > Po Lu, what were the reasons for that particular part of the commit? > >> > >> The scale applied by image-scaling-factor is liable to differ by > >> display > > > > How so? Please elaborate. > > When it is set to `auto' (the default value), the scaling factor to be > applied is decided by the configuration of a frame, namely, its > FRAME_COLUMN_WIDTH. So when the default font changes, all the images are supposed to be resized? Does that really happen, and if so, is that a good idea in all cases? > >> and computing the default scale in Lisp would result in images > >> being displayed with an incorrect scale in the presence of multiple > >> displays. > > > > How does the above changeset solve this problem, then? > > By moving its application to image.c, which knows where an image is > being displayed and can apply specific scales for each frame. But, as this bug seems to indicate, that solution doesn't always work? > >> Image caches must be flushed when image-scaling-factor is modified, > >> unless it is set to `auto' and a display's scale changes, because > >> image.c has no means of detecting variable modifications and so only the > >> latter event can be automatically detected. > > > > Please describe the issue in more detail, as I don't think I follow > > what you are saying here. If we need to detect changes in variables, > > we can use the add-variable-watcher technique, similar to what we do > > in frame.el with variables that need to force redisplay (but maybe I > > don't understand the problem you are describing). > > > > In any case, I don't think changes in image-scaling-factor are > > supposed to be immediately reflected on display, if that's what you > > have in mind. This is not the documented effect of this variable. > > What I am trying to communicate is that changes to > `image-scaling-factor' must be accompanied by flushing the image cache > if it is to take effect on all previously displayed images. This isn't > a problem, and the OP should simply flush the image cache after > modifying image-scaling-factor, rather than rely on the erroneous > behavior of find-image which was removed. OK, so do you consider the solution of recording the scale factor in the cache a reasonable one?