From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Carlos Pita Newsgroups: gmane.emacs.bugs Subject: bug#37932: [PATCH] Support hidpi fringes and images with Cairo Date: Sun, 27 Oct 2019 14:08:02 -0300 Message-ID: References: <83r22zvpg4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="8894"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 37932@debbugs.gnu.org To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 27 18:09:23 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iOm2c-0002AX-SB for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Oct 2019 18:09:23 +0100 Original-Received: from localhost ([::1]:46012 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOm2a-00006V-S1 for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Oct 2019 13:09:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55291) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOm2M-00005L-85 for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2019 13:09:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iOm2K-000052-7M for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2019 13:09:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34645) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iOm2K-0008WO-2x for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2019 13:09:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iOm2J-0005Mu-PT for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2019 13:09:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Carlos Pita Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Oct 2019 17:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37932 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 37932-submit@debbugs.gnu.org id=B37932.157219610220580 (code B ref 37932); Sun, 27 Oct 2019 17:09:01 +0000 Original-Received: (at 37932) by debbugs.gnu.org; 27 Oct 2019 17:08:22 +0000 Original-Received: from localhost ([127.0.0.1]:43466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iOm1d-0005Ls-St for submit@debbugs.gnu.org; Sun, 27 Oct 2019 13:08:22 -0400 Original-Received: from mail-yb1-f181.google.com ([209.85.219.181]:44479) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iOm1c-0005La-0x for 37932@debbugs.gnu.org; Sun, 27 Oct 2019 13:08:20 -0400 Original-Received: by mail-yb1-f181.google.com with SMTP id w5so2987825ybs.11 for <37932@debbugs.gnu.org>; Sun, 27 Oct 2019 10:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RHT67q43UEv1d1/QMK100C35SalWazV97qa4HlV6yDw=; b=Loa1R3SRvKcooYZRS+7pJ5ZqLPqwjUoiF+7NMCahc4hJ2hCRbFvOIoMNz5tVLei0kc 7TitijjDOtwqvGSuz2HG3FOBsIe81u5oGBS2OtmDexKpnCkL78IK182mHgmMqTGGo/Tx V59JH61RIncQWm262nfUZm0er5ZqxT7TrRNtKDz2earIx5npsHiO75A0sS/wyx4tpd4a Jk3sxCGozx6b8fslxitd3vlPNBDro7Jz3nYaa22W+9CqltYRC6Od+MKjcF1C5fedkTRk 0DWss/At6iP28VTUr0R3M2w+9afmFfe/SAmijnuDBi86MgfYZSRtjBFr6l+/wfs+sttH OB5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RHT67q43UEv1d1/QMK100C35SalWazV97qa4HlV6yDw=; b=bql1girs4FP4MZ+rlAUHfUSYcBGUekzEbHu5kGY3E2MI5mDJByWDy4pqPrpHe/n1/w OBkMH+JQ7pPP0VLL69dpwt8t49u4FmcfoVeqjNjSKWLtSxo78CsZZBlmXM7nXcLZPHl2 roLY7hF/RPfs3gjr2P+mJLpMmSZiSkxqKbnGEABD/+TuOGV+0eFGKYo2FazHoWhl3Cbb 8eVrCtqItCi8zLLnIlyOoZSf/WeQkn7S9UUO01bvznmI+Y8/yU72KD+6RuZJQ/6FsoYg Og/WIN47bU4CTGQehrr26ENpntRR1FxzaASiC0i2x4cPYNz8m/LkgQB6V8YIdz4BaQaR yb8g== X-Gm-Message-State: APjAAAWd5BbgPP40iQSSGgAcB0P3GDMWuKCfAsnEdsgSG6b2f/szCB55 Rdu/OAyOLhgEArGOzuA5dHcs/1vsOygBb2JoaI4= X-Google-Smtp-Source: APXvYqzwL7VM2CqlJWv6e9FAU1SwhNOb7IuQVHzCvLBYqvBFBXXqyGDvbtF6yJTRYHQtfJrABVrPUqIxpCjVFY9D72Y= X-Received: by 2002:a25:be48:: with SMTP id d8mr11736402ybm.353.1572196094286; Sun, 27 Oct 2019 10:08:14 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:170260 Archived-At: > If I read the patch correctly, you now auto-scale inside image.c, > which shouldn't change anything when not using :scale. What's the Right, AFAICS scaling of images was always done inside image.c, that's where transformation routines are coded. The difference is more in the usage of the :scale parameter. Previously there were two cases: 1. The caller doesn't pass a :scale in the spec. Then a :scale property compensating for the dpi of the screen is automatically added to the spec if the image-scaling-factor customization option is set to 'auto. The computed scale factor assumes a representative character to be 10px width. 2. The caller passes a :scale in the spec. Then the image is scaled using this number and no extra dpi-adapting-scaling is done. I see two shortcomings with this approach: a. One I've already mentioned above: scaling required by the application shouldn't interfere with scaling done to fit screen resolution, which is a concern at a very different level. b. Moreover, I'm not sure how compatible is this 10px char width assumption with the 96dpi base resolution assumed to compute scale factors in xterm.c and w32term.c. OTOH, the 96dpi assumption is compatible with what gtk does. Anyway, with my patch each platform is able to set a different base resolution if that's necessary. > effect when code passes in eg :scale 2? Autoscaling + frame scaling, > so for a frame where scale =3D=3D 2 we get * 4? I guess that would be > sensible, but we=CA=BCd need to explain it clearly. [1] User code should be mostly unaware of the underlying resolution except for very specialized cases. Currently, that is reflected in the default 'auto image-scaling-factor. It's true that, as I commented in point 1 above, nowadays one can pass a explicit :scale in order to turn auto-scaling off, although in most cases that would probably introduce a bug by *inadvertently* turning auto-scaling off. We can add another property to the spec in order to enforce real pixel size, or the user can divide the desired scale by the result of image-compute-scaling-factor (in the same way the xterm backend is circumventing gtk auto-scaling by applying the inverse scale operation first). I prefer adding a new spec property to turn-off auto-scaling, because that way both image-compute-scaling-factor and image-scaling-factor could be removed from the codebase and also the inconsistency between 96dpi and 10px criteria wouldn't be a problem any more.