From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.devel Subject: Re: "Fix" sag scaling for hidpi Date: Wed, 10 Feb 2021 13:00:52 -0500 Message-ID: References: <07D5E64D-DAD0-45B3-B272-627A73D7CBAE@gmail.com> <7308DB2C-27A5-4227-A1F9-9949EE558052@gmail.com> <87sg6alweo.fsf@gnus.org> <87pn1erewq.fsf@gmail.com> <87wnvlecrw.fsf@gnus.org> <83sg69o3av.fsf@gnu.org> <87mtwhctte.fsf@gnus.org> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34292"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , emacs-devel , Eli Zaretskii , monnier@iro.umontreal.ca, Robert Pluim To: Alan Third Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 10 19:02:58 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 1l9tpI-0008ll-V1 for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Feb 2021 19:02:56 +0100 Original-Received: from localhost ([::1]:50488 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9tpH-0003gt-VM for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Feb 2021 13:02:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33160) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9tnP-0002iz-Ee for emacs-devel@gnu.org; Wed, 10 Feb 2021 13:00:59 -0500 Original-Received: from mail-qv1-xf35.google.com ([2607:f8b0:4864:20::f35]:43894) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l9tnN-0004vT-H3; Wed, 10 Feb 2021 13:00:59 -0500 Original-Received: by mail-qv1-xf35.google.com with SMTP id j13so1265263qvu.10; Wed, 10 Feb 2021 10:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=B737/2QPY4JQ15HURSwx2PUvn7YIhGufK8CUkkuJRko=; b=cQsaeodBQ1Di/zdtrvjdliMnVWLc3Cvqa+O5oFRyzbzZanFN3eSE9Fpt+6EeinERB9 rvRT3EseUxjQT015bV1lCoeNGeSR2zxf0arPfVBOE1FAerRYapuw0cIWKyVaqubflvu/ HJmxWW38BVTYk2vmnvdWyOFGZdzOAwWB9KGxTerD/orxOFo4ZTG0GsRlJwn3XVJUeLVO j1bVYJByAOKz52qzledJF3RliNowsjASxAMzxc0rTjYNerExRDsuJX+2jIyglh1WE4v2 mx6viufQOoK7SC5b6wR2UQ/SwzzUIZAjrTFT1RJ1cgNK21wimAOXvCnkXsmMIDdXdRRt udmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=B737/2QPY4JQ15HURSwx2PUvn7YIhGufK8CUkkuJRko=; b=hfjAwtZ+MZKGRq8mDbFgXn9PMK7ENjRxUpPuK7rImKw9jTuc6BByPUR2qudQhpUdL3 T96UrZM61usP9Ydeh5qAiQyv4tB3H+MD6bQExclBL4MQJnfyomcnzxyFyvjRrkuufUHN dccoFKby+ScTzioanij1mO3UM1F5aOfqPzqpdV4IHsYTPDTOjbonhNTxbIFxM7ZmRfO3 hMCKdWClkV/Ayzt4KstOpXY6MpatQSIfbBSd+deT/IFKqwaR3wnOPJnJUo7HOJmjcMEL oKl2I/IlCTDtFowU5PgRSPqQglbxw4orYY9HZhsr11u05oDYTC0XRLdwBVPXsfhj6HWs LZKQ== X-Gm-Message-State: AOAM530dyWfFKovc0m9w5QzrPUbCJDP7rparbbYqYEfCQp0X4HBM3hMl XtNkZS5d7wd6pUy8MygOPP8= X-Google-Smtp-Source: ABdhPJxyZqwsAGJv6iOTqgXcTMqeTQg2PB9dNePUiNilBr4Witeao+ZAEc609Cq7sC44NCH/+i1ISw== X-Received: by 2002:a05:6214:21a5:: with SMTP id t5mr4126602qvc.20.1612980055049; Wed, 10 Feb 2021 10:00:55 -0800 (PST) Original-Received: from ?IPv6:2601:98a:4200:9210:e890:d6db:6ecd:68fc? ([2601:98a:4200:9210:e890:d6db:6ecd:68fc]) by smtp.gmail.com with ESMTPSA id i6sm1731347qti.30.2021.02.10.10.00.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Feb 2021 10:00:53 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.3654.60.0.2.21) Received-SPF: pass client-ip=2607:f8b0:4864:20::f35; envelope-from=casouri@gmail.com; helo=mail-qv1-xf35.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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.23 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:264316 Archived-At: >=20 > One of the main problems I've had with trying to find a solution is to > work out what we want to actually happen. >=20 > If I open an image on an emacs frame it makes sense that the image > should be displayed 1:1 with the physical pixels no matter what the > scale factor is. >=20 > If that frame is then moved to another display with a different scale > factor do we then resize the image according to the change in scale > factor (so it's still 1:1 with the physical pixels), or keep it the > same (logical) size? >=20 > I think we probably want to keep it the same (logical) size, so I > think we need to, as described elsewhere, expose the scale factor to > lisp so that create-image can calculate :scale rather than trying to > calculate it on-the-fly in C code. I agrees that we should keep the logical size, i.e., keep the size = comparing against text. If we expose correct physical size, packages = that generate bitmaps for display can generate crisp bitmaps with = correct pixel size. IIUC, a high-res image with :scale 0.5 should work across high and = low-res displays. So ideally any package that wants to generate crisp = bitmap can get the physical size and pixel-ratio from Emacs, generate = the image and set :scale to 1/pixel-ratio. And this image works across = different displays. >=20 > We'll probably have to do more fiddling with SVGs though, since they > can define sizes in real-world units, like cm or inches, so the dpi > has to match the physical pixels, and if we move to a different screen > and regenerate the SVG the DPI will be different but the scale likely > won't be recalculated and the image will change size. To simplify things, maybe we can assume DPI is 96. I.e., assume 1 inch =3D= 96 logical pixels =3D 96 * pixel-ratio physical pixels. Obviously, if we can get DPI information from all terminals, then we = could use that information. But from your previous message it doesn=E2=80=99= t seem easy. >=20 > Perhaps we need to let lisp set the DPI for an SVG (and other scalable > image types) as well as the scale. >=20 > And this is further complicated by the fact macOS uses a "fake" DPI > that has no relation to physical pixel size at all! >=20 > And, of course, none of this will help when the lisp code doesn't use > create-image. >=20 > I hope this makes sense, I find this hard to describe. > --=20 > Alan Third For SVGs I think we should automatically handle the pixel ratio and dpi = so the image is always crisp and lisp doesn=E2=80=99t need to do = anything (don=E2=80=99t need to add the :scale attribute or anything). For bitmap images I think we display them in their physical size and let = lisp alter the size by the :scale attribute. For :width and :height attributes, I think they should be in logical = pixels.Because the ratio of logical pixels and other text in a buffer = doesn=E2=80=99t change when you drag a frame across different displays. = So if the user set an image to have certain :width and drag the frame to = a different display, the image doesn=E2=80=99t change its size comparing = to everything else in the buffer. Yuan