[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: exposing x_get_scale_factor into elisp level
From: |
Alan Third |
Subject: |
Re: exposing x_get_scale_factor into elisp level |
Date: |
Sun, 4 Apr 2021 11:38:43 +0100 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: exposing x_get_scale_factor into elisp level,
Alan Third <=