* Re: exposing x_get_scale_factor into elisp level
2021-03-24 21:20 ` Evgeny Zajcev
@ 2021-03-24 22:55 ` Alan Third
2021-03-25 1:32 ` Yuan Fu
2021-04-04 10:38 ` Alan Third
2 siblings, 0 replies; 6+ messages in thread
From: Alan Third @ 2021-03-24 22:55 UTC (permalink / raw)
To: Evgeny Zajcev; +Cc: emacs-devel
[-- 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
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: exposing x_get_scale_factor into elisp level
2021-03-24 21:20 ` Evgeny Zajcev
2021-03-24 22:55 ` Alan Third
@ 2021-03-25 1:32 ` Yuan Fu
2021-04-04 10:38 ` Alan Third
2 siblings, 0 replies; 6+ messages in thread
From: Yuan Fu @ 2021-03-25 1:32 UTC (permalink / raw)
To: Evgeny Zajcev; +Cc: Alan Third, emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: exposing x_get_scale_factor into elisp level
2021-03-24 21:20 ` Evgeny Zajcev
2021-03-24 22:55 ` Alan Third
2021-03-25 1:32 ` Yuan Fu
@ 2021-04-04 10:38 ` Alan Third
2 siblings, 0 replies; 6+ messages in thread
From: Alan Third @ 2021-04-04 10:38 UTC (permalink / raw)
To: Evgeny Zajcev; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread