Re: exposing x_get_scale_factor into elisp level

[Yuan Fu <casouri@gmail.com>]

[-- 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 --]