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: Which should the display-pixel-width function return, physical pixel width or logical pixel width? Date: Fri, 1 Jan 2021 16:51:21 -0500 Message-ID: <111C5580-03ED-496F-AEC7-D2C30E52B9E1@gmail.com> References: <20210101.234418.2112625777155657071.masm@luna.pink.masm11.me> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) 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="29660"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Yuuki Harano Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 01 22:52:15 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 1kvSLC-0007TW-Ls for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Jan 2021 22:52:10 +0100 Original-Received: from localhost ([::1]:50520 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvSLB-0001BE-LM for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Jan 2021 16:52:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57966) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvSKT-0000kN-Rr for emacs-devel@gnu.org; Fri, 01 Jan 2021 16:51:25 -0500 Original-Received: from mail-qk1-x731.google.com ([2607:f8b0:4864:20::731]:41493) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kvSKS-0006SN-9T for emacs-devel@gnu.org; Fri, 01 Jan 2021 16:51:25 -0500 Original-Received: by mail-qk1-x731.google.com with SMTP id 19so18858147qkm.8 for ; Fri, 01 Jan 2021 13:51:23 -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=sMquXuuvbX+vZdDLXcpXoPDRtDxc3mWEVZd+vzT+8Dk=; b=IfpCSl0g0zHHI2PEvZ91gV9NoZH9MWODrjkQPcE78XRpqDcxQdJBcDyMsXv3g1+KoJ j0r2b5R2joV71YIRhxtJ8KF9yPBDX8tHG9M5LxvK/cFtfASe1gJQmjPaAdhLZk/Uu1mb HPk9IiXKqbBKretstIktQ+yZm1mkLtRgR1b4YvrLZxIU9qn4Y8ANB9K0XT6+OBvG5QQP i2HumgLsyLe9RgL3OjDrtP1t26sqhqPKmw7ZsjzJjgh7EDlOY7gnJm7pktYFt95GWCqV trXe8cEhxEN8l2hMsfCuMYC5IqsR+stOhmiLLzXL2uwBEUkoDSL/BSLsddJXTzwPZp/S rmEQ== 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=sMquXuuvbX+vZdDLXcpXoPDRtDxc3mWEVZd+vzT+8Dk=; b=UixZMKfdKVstA7/FwVllDpseghbX7yuHZS0NzblcCsOGt1WepQLnHbiu07+rDxLpBS DfEuv8GHhSSWzSECVGbOFFMjNh7HL/uAPOGIURgdOfnN3s56XqtYi5wFOIN9J2ATehpD O6kVp/g9+aojrJNfU33kKs6pS1lDUW6cAqQVGzTQLizEIHODtQnAkZh9cvF/oJY66LTL lwl0B7HdGrf3gfD7yVPPjZgLDk5ZnWKlGvwLelpZW8ZT3Kjp3H0+zwcqTAr8u9SF/88B u6AOlwRYMTWiRvXr842C5CjKgA0s4TxbNYUrZ8EccpwdEj/sAmhTV37Dl/Qol4oa7wQL wPTg== X-Gm-Message-State: AOAM531GYCBtkBy+U3jZka0FNeX5MC3SKhFbeI4o//aQBPILPsgvQmVX MxeonWrNEs9My9BsDldtljrcGYQ9EasoPQ== X-Google-Smtp-Source: ABdhPJyfB2/Ntip0pgF7JunPydHiu/DS+Mn55drulgWXj9XDNCqOp/2suxkUPd4ToLF/dCYbR7zFsg== X-Received: by 2002:a37:62cf:: with SMTP id w198mr63114081qkb.363.1609537882902; Fri, 01 Jan 2021 13:51:22 -0800 (PST) Original-Received: from ?IPv6:2601:98a:4200:9210:465:abc3:6591:f54a? ([2601:98a:4200:9210:465:abc3:6591:f54a]) by smtp.gmail.com with ESMTPSA id q73sm32762228qke.16.2021.01.01.13.51.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jan 2021 13:51:22 -0800 (PST) In-Reply-To: <20210101.234418.2112625777155657071.masm@luna.pink.masm11.me> X-Mailer: Apple Mail (2.3654.40.0.2.32) Received-SPF: pass client-ip=2607:f8b0:4864:20::731; envelope-from=casouri@gmail.com; helo=mail-qk1-x731.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:262265 Archived-At: > On Jan 1, 2021, at 9:44 AM, Yuuki Harano wrote: >=20 > Hi, I'm pgtk developer. >=20 > Currently, display-pixel-width of vanilla emacs returns physical pixel > width. i.e. it returns 3840 even if GDK_SCALE=3D2 when using = 3840x2160. >=20 > Some emacs lisps (like preview in auctex) use display-pixel-width and > display-mm-width to calculate physical dpi. >=20 > I think it is strange. On multi-monitor environment, > display-pixel-width and display-mm-width contains all the monitors, > that may be different dpi. The result dpi is between the two. > Those emacs lisps should use per-monitor information. >=20 > Currently, pgtk emacs returns logical pixel width, i.e. 1920, because > Gdk returns it. On multi-monitor environment, Gdk returns 1920 + > something. >=20 > I'm going to add scale-factor in per-monitor information to support > scaling. dpi-sensitive emacs lisps can extract logical pixel width, > mm width, and scale-factor from it, and calculate dpi. >=20 > "Monitor" is a recent concenpt. > If pgtk emacs returns logical one, then compatibility may be broken. > If pgtk emacs returns physical one, then those emacs lisps continue to > do strange calculation. >=20 > What should the display-pixel-width function (and > display-monitor-attributes-list) return, physical pixel width, logical > pixel width, or implementation-dependent? The documentation of > display-pixel-width seems to say nothing about that. > --=20 > Yuuki Harano >=20 As hidpi screens getting more common, we should separate pixel sizes = reported from frontends into logical and physical pixels. This problem = also makes images on Mac fuzzy. Currently ns frontend can distinct = between logical and physical pixel size, from Yuuki=E2=80=99s post it = seems pgtk can, too. Does other frontends have such ability? Yuan