* Which should the display-pixel-width function return, physical pixel width or logical pixel width?
@ 2021-01-01 14:44 Yuuki Harano
2021-01-01 21:51 ` Yuan Fu
2021-01-02 6:04 ` Lars Ingebrigtsen
0 siblings, 2 replies; 6+ messages in thread
From: Yuuki Harano @ 2021-01-01 14:44 UTC (permalink / raw)
To: emacs-devel
Hi, I'm pgtk developer.
Currently, display-pixel-width of vanilla emacs returns physical pixel
width. i.e. it returns 3840 even if GDK_SCALE=2 when using 3840x2160.
Some emacs lisps (like preview in auctex) use display-pixel-width and
display-mm-width to calculate physical dpi.
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.
Currently, pgtk emacs returns logical pixel width, i.e. 1920, because
Gdk returns it. On multi-monitor environment, Gdk returns 1920 +
something.
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.
"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.
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.
--
Yuuki Harano
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Which should the display-pixel-width function return, physical pixel width or logical pixel width?
2021-01-01 14:44 Which should the display-pixel-width function return, physical pixel width or logical pixel width? Yuuki Harano
@ 2021-01-01 21:51 ` Yuan Fu
2021-01-02 7:40 ` Yuuki Harano
2021-01-02 6:04 ` Lars Ingebrigtsen
1 sibling, 1 reply; 6+ messages in thread
From: Yuan Fu @ 2021-01-01 21:51 UTC (permalink / raw)
To: Yuuki Harano; +Cc: emacs-devel
> On Jan 1, 2021, at 9:44 AM, Yuuki Harano <masm+emacs@masm11.me> wrote:
>
> Hi, I'm pgtk developer.
>
> Currently, display-pixel-width of vanilla emacs returns physical pixel
> width. i.e. it returns 3840 even if GDK_SCALE=2 when using 3840x2160.
>
> Some emacs lisps (like preview in auctex) use display-pixel-width and
> display-mm-width to calculate physical dpi.
>
> 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.
>
> Currently, pgtk emacs returns logical pixel width, i.e. 1920, because
> Gdk returns it. On multi-monitor environment, Gdk returns 1920 +
> something.
>
> 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.
>
> "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.
>
> 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.
> --
> Yuuki Harano
>
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’s post it seems pgtk can, too. Does other frontends have such ability?
Yuan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Which should the display-pixel-width function return, physical pixel width or logical pixel width?
2021-01-01 21:51 ` Yuan Fu
@ 2021-01-02 7:40 ` Yuuki Harano
2021-01-02 10:31 ` Alan Third
0 siblings, 1 reply; 6+ messages in thread
From: Yuuki Harano @ 2021-01-02 7:40 UTC (permalink / raw)
To: casouri; +Cc: emacs-devel
Hi,
On Fri, 1 Jan 2021 16:51:21 -0500,
Yuan Fu <casouri@gmail.com> wrote:
> 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’s post
> it seems pgtk can, too. Does other frontends have such ability?
* ns
frontend is logical.
when creating image area, its size is physical.
ns-display-monitor-attributes-list does nothing about scaling. maybe returns logical.
emacs internal is logical.
* x11+gtk
gdk frontend is logical.
x-display-monitor-attributes-list returns physical.
emacs internal is physical.
* w32
scaling is not supported.
* pgtk (current)
gdk frontend is logical.
pgtk-display-monitor-attributes-list returns logical.
emacs internal is logical.
--
Yuuki Harano
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Which should the display-pixel-width function return, physical pixel width or logical pixel width?
2021-01-02 7:40 ` Yuuki Harano
@ 2021-01-02 10:31 ` Alan Third
0 siblings, 0 replies; 6+ messages in thread
From: Alan Third @ 2021-01-02 10:31 UTC (permalink / raw)
To: Yuuki Harano; +Cc: casouri, emacs-devel
On Sat, Jan 02, 2021 at 04:40:07PM +0900, Yuuki Harano wrote:
>
> * ns
> frontend is logical.
> when creating image area, its size is physical.
> ns-display-monitor-attributes-list does nothing about scaling. maybe returns logical.
> emacs internal is logical.
macOS hides the scaling from us almost completely, so practically
everything it does is logical, not physical. Certainly all the data
returned to lisp is logical.
--
Alan Third
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Which should the display-pixel-width function return, physical pixel width or logical pixel width?
2021-01-01 14:44 Which should the display-pixel-width function return, physical pixel width or logical pixel width? Yuuki Harano
2021-01-01 21:51 ` Yuan Fu
@ 2021-01-02 6:04 ` Lars Ingebrigtsen
2021-01-03 8:34 ` Yuuki Harano
1 sibling, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2021-01-02 6:04 UTC (permalink / raw)
To: Yuuki Harano; +Cc: emacs-devel
Yuuki Harano <masm+emacs@masm11.me> writes:
> 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.
Sounds good.
> "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.
>
> 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.
I think they should return the physical pixel width.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-01-03 8:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-01-01 14:44 Which should the display-pixel-width function return, physical pixel width or logical pixel width? Yuuki Harano
2021-01-01 21:51 ` Yuan Fu
2021-01-02 7:40 ` Yuuki Harano
2021-01-02 10:31 ` Alan Third
2021-01-02 6:04 ` Lars Ingebrigtsen
2021-01-03 8:34 ` Yuuki Harano
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).