From: Alan Third <alan@idiocy.org>
To: Evgeny Zajcev <lg.zevlg@gmail.com>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: exposing x_get_scale_factor into elisp level
Date: Wed, 24 Mar 2021 22:55:42 +0000 [thread overview]
Message-ID: <YFvDbowBIR8i5Gmk@breton.holly.idiocy.org> (raw)
In-Reply-To: <CAO=W_ZquEBqx9dJqeWYT4h2+jsXFO5c1W9AUZSe+KVcg-8Y6Ag@mail.gmail.com>
[-- 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
next prev parent reply other threads:[~2021-03-24 22:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-21 23:07 exposing x_get_scale_factor into elisp level Evgeny Zajcev
2021-03-24 20:27 ` Alan Third
2021-03-24 21:20 ` Evgeny Zajcev
2021-03-24 22:55 ` Alan Third [this message]
2021-03-25 1:32 ` Yuan Fu
2021-04-04 10:38 ` Alan Third
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YFvDbowBIR8i5Gmk@breton.holly.idiocy.org \
--to=alan@idiocy.org \
--cc=emacs-devel@gnu.org \
--cc=lg.zevlg@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).