exposing x_get_scale_factor into elisp level

exposing x_get_scale_factor into elisp level

[Evgeny Zajcev]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

HiDPI is very common nowadays.  Internally Emacs has decent support for
HiDPI displays.  However elisp code, that generates non-svg images don't
have any idea that logical pixel may differ from physical one, resulting in
generating images in low resolution on HiDPI displays.

Emacs internally has a notion about HiDPI displays, such as
`x_get_scale_factor`, maybe expose this function to elisp level, so
packages may utilize it to generate images in highres?

Or `(> (round (/ (display-pixel-height) (/ (display-mm-height) 25.4))) 96)`
is good enough to detect HiDPI displays?

Thanks

-- 
lg

[-- Attachment #2: Type: text/html, Size: 806 bytes --]

Re: exposing x_get_scale_factor into elisp level

[Alan Third]

On Mon, Mar 22, 2021 at 02:07:41AM +0300, Evgeny Zajcev wrote:
> HiDPI is very common nowadays.  Internally Emacs has decent support for
> HiDPI displays.  However elisp code, that generates non-svg images don't
> have any idea that logical pixel may differ from physical one, resulting in
> generating images in low resolution on HiDPI displays.
> 
> Emacs internally has a notion about HiDPI displays, such as
> `x_get_scale_factor`, maybe expose this function to elisp level, so
> packages may utilize it to generate images in highres?

On NS platforms (macOS and GNUstep) and, I believe, native GTK the
scale factor is how much the TOOLKIT scales things up for display.

But on plain X it's actually how much YOU have to scale things up to
get to "logical" pixels. Emacs on X only uses the logical sizes for
the toolbar and possibly some other window chrome, and then only on
GTK builds.

I couldn't work out how to reconcile the two approaches, and didn't
actually need it for the SVG work, so I forgot about it. It may make
sense to just ignore this stuff on X once we have PGTK merged.

Windows appears to be completely different, providing some three or
four different approaches to HiDPI.
-- 
Alan Third

Re: exposing x_get_scale_factor into elisp level

[Evgeny Zajcev]

[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]

ср, 24 мар. 2021 г. в 23:27, Alan Third <alan@idiocy.org>:

> On Mon, Mar 22, 2021 at 02:07:41AM +0300, Evgeny Zajcev wrote:
> > HiDPI is very common nowadays.  Internally Emacs has decent support for
> > HiDPI displays.  However elisp code, that generates non-svg images don't
> > have any idea that logical pixel may differ from physical one, resulting
> in
> > generating images in low resolution on HiDPI displays.
> >
> > Emacs internally has a notion about HiDPI displays, such as
> > `x_get_scale_factor`, maybe expose this function to elisp level, so
> > packages may utilize it to generate images in highres?
>
> On NS platforms (macOS and GNUstep) and, I believe, native GTK the
> scale factor is how much the TOOLKIT scales things up for display.
>

The problem we hit on MacOS is that line height is reported in logical
pixels, and we generate PNG images using that line height value.  This
results in poor PNG quality since the physical pixel is x4 times larger.
Now we use heavy heuristics to workaround this, it will be great to have
some general approach as Emacs do internally (`x_get_scale_factor')

Unfortunately, we can't use SVG instead of PNG at the moment

-- 
lg

[-- Attachment #2: Type: text/html, Size: 1682 bytes --]

Re: exposing x_get_scale_factor into elisp level

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]

On Thu, Mar 25, 2021 at 12:20:09AM +0300, Evgeny Zajcev wrote:
> ср, 24 мар. 2021 г. в 23:27, Alan Third <alan@idiocy.org>:
> 
> > On Mon, Mar 22, 2021 at 02:07:41AM +0300, Evgeny Zajcev wrote:
> > > HiDPI is very common nowadays.  Internally Emacs has decent support for
> > > HiDPI displays.  However elisp code, that generates non-svg images don't
> > > have any idea that logical pixel may differ from physical one, resulting
> > in
> > > generating images in low resolution on HiDPI displays.
> > >
> > > Emacs internally has a notion about HiDPI displays, such as
> > > `x_get_scale_factor`, maybe expose this function to elisp level, so
> > > packages may utilize it to generate images in highres?
> >
> > On NS platforms (macOS and GNUstep) and, I believe, native GTK the
> > scale factor is how much the TOOLKIT scales things up for display.
> >
> 
> The problem we hit on MacOS is that line height is reported in logical
> pixels, and we generate PNG images using that line height value.  This
> results in poor PNG quality since the physical pixel is x4 times larger.
> Now we use heavy heuristics to workaround this, it will be great to have
> some general approach as Emacs do internally (`x_get_scale_factor')

My point, which wasn't clear, is that x_get_scale_factor is not
general.

IMO exposing its output to lisp is likely to just cause confusion.

That said, I've attached an implementation that ignores X and possibly
won't work for Windows.

-- 
Alan Third

[-- Attachment #2: 0001-Implement-frame-scale-factor.patch --]
[-- Type: text/plain, Size: 2691 bytes --]

From 96f96c5e9da6db91509afea4c1ac9b1ba04ddaae Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Wed, 24 Mar 2021 22:50:03 +0000
Subject: [PATCH] Implement frame-scale-factor

* src/frame.c (Fframe_scale_factor): New function.
(syms_of_frame): Add frame-scale-factor.
* src/frame.h: Add FRAME_SCALE_FACTOR.
* src/image.c: Move FRAME_SCALE_FACTOR to frame.h.
---
 src/frame.c | 12 ++++++++++++
 src/frame.h |  7 +++++++
 src/image.c |  8 --------
 3 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/src/frame.c b/src/frame.c
index a62347c1fb..fd649ff0fa 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -3744,6 +3744,17 @@ DEFUN ("set-frame-window-state-change", Fset_frame_window_state_change,
   return (FRAME_WINDOW_STATE_CHANGE (f) = !NILP (arg)) ? Qt : Qnil;
 }
 
+DEFUN ("frame-scale-factor", Fframe_scale_factor, Sframe_scale_factor,
+       0, 1, 0,
+       doc: /* Return FRAMEs scale factor.
+The scale factor is the amount a logical pixel size must be multiplied
+to find the real number of pixels.  */)
+     (Lisp_Object frame)
+{
+  struct frame *f = decode_live_frame (frame);
+
+  return (make_float (FRAME_SCALE_FACTOR (f)));
+}
 \f
 /***********************************************************************
 				Frame Parameters
@@ -6457,6 +6468,7 @@ focus (where a frame immediately loses focus when it's left by the mouse
   defsubr (&Sframe_pointer_visible_p);
   defsubr (&Sframe_window_state_change);
   defsubr (&Sset_frame_window_state_change);
+  defsubr (&Sframe_scale_factor);
 
 #ifdef HAVE_WINDOW_SYSTEM
   defsubr (&Sx_get_resource);
diff --git a/src/frame.h b/src/frame.h
index 9ddcb4c681..9963112036 100644
--- a/src/frame.h
+++ b/src/frame.h
@@ -907,6 +907,13 @@ #define FRAME_HAS_MINIBUF_P(f)					\
   (WINDOWP (f->minibuffer_window)				\
    && XFRAME (XWINDOW (f->minibuffer_window)->frame) == f)
 
+/* Scale factor of frame F.  */
+#if defined HAVE_NS
+# define FRAME_SCALE_FACTOR(f) (FRAME_NS_P (f) ? ns_frame_scale_factor (f) : 1)
+#else
+# define FRAME_SCALE_FACTOR(f) 1;
+#endif
+
 /* Pixel width of frame F.  */
 #define FRAME_PIXEL_WIDTH(f) ((f)->pixel_width)
 
diff --git a/src/image.c b/src/image.c
index 3d504effa6..24089e5cb0 100644
--- a/src/image.c
+++ b/src/image.c
@@ -135,14 +135,6 @@ #define PIX_MASK_DRAW	1
 # define COLOR_TABLE_SUPPORT 1
 #endif
 
-#ifdef HAVE_RSVG
-#if defined HAVE_NS
-# define FRAME_SCALE_FACTOR(f) ns_frame_scale_factor (f)
-#else
-# define FRAME_SCALE_FACTOR(f) 1;
-#endif
-#endif
-
 static void image_disable_image (struct frame *, struct image *);
 static void image_edge_detection (struct frame *, struct image *, Lisp_Object,
                                   Lisp_Object);
-- 
2.29.2

Re: exposing x_get_scale_factor into elisp level

[Yuan Fu]

[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]



> On Mar 24, 2021, at 5:20 PM, Evgeny Zajcev <lg.zevlg@gmail.com> wrote:
> 
> 
> 
> ср, 24 мар. 2021 г. в 23:27, Alan Third <alan@idiocy.org <mailto:alan@idiocy.org>>:
> On Mon, Mar 22, 2021 at 02:07:41AM +0300, Evgeny Zajcev wrote:
> > HiDPI is very common nowadays.  Internally Emacs has decent support for
> > HiDPI displays.  However elisp code, that generates non-svg images don't
> > have any idea that logical pixel may differ from physical one, resulting in
> > generating images in low resolution on HiDPI displays.
> > 
> > Emacs internally has a notion about HiDPI displays, such as
> > `x_get_scale_factor`, maybe expose this function to elisp level, so
> > packages may utilize it to generate images in highres?
> 
> On NS platforms (macOS and GNUstep) and, I believe, native GTK the
> scale factor is how much the TOOLKIT scales things up for display.
> 
> The problem we hit on MacOS is that line height is reported in logical pixels, and we generate PNG images using that line height value.  This results in poor PNG quality since the physical pixel is x4 times larger.  Now we use heavy heuristics to workaround this, it will be great to have some general approach as Emacs do internally (`x_get_scale_factor')
> 
> Unfortunately, we can't use SVG instead of PNG at the moment
> 

Meanwhile, maybe you can just generate a 2x png image and scale it down, regardless of the true scale factor?

Yuan

[-- Attachment #2: Type: text/html, Size: 3262 bytes --]

Re: exposing x_get_scale_factor into elisp level

[Alan Third]

On Thu, Mar 25, 2021 at 12:20:09AM +0300, Evgeny Zajcev wrote:
> ср, 24 мар. 2021 г. в 23:27, Alan Third <alan@idiocy.org>:
> 
> > On Mon, Mar 22, 2021 at 02:07:41AM +0300, Evgeny Zajcev wrote:
> > > HiDPI is very common nowadays.  Internally Emacs has decent support for
> > > HiDPI displays.  However elisp code, that generates non-svg images don't
> > > have any idea that logical pixel may differ from physical one, resulting
> > in
> > > generating images in low resolution on HiDPI displays.
> > >
> > > Emacs internally has a notion about HiDPI displays, such as
> > > `x_get_scale_factor`, maybe expose this function to elisp level, so
> > > packages may utilize it to generate images in highres?
> >
> > On NS platforms (macOS and GNUstep) and, I believe, native GTK the
> > scale factor is how much the TOOLKIT scales things up for display.
> >
> 
> The problem we hit on MacOS is that line height is reported in logical
> pixels, and we generate PNG images using that line height value.  This
> results in poor PNG quality since the physical pixel is x4 times larger.
> Now we use heavy heuristics to workaround this, it will be great to have
> some general approach as Emacs do internally (`x_get_scale_factor')
> 
> Unfortunately, we can't use SVG instead of PNG at the moment

I've pushed a version of this to master, so you can use
'frame-scale-factor'.

-- 
Alan Third