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')

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

0001-Implement-frame-scale-factor.patch
Description: Text document