bug#37770: [PATCH] Expose scale factor through the redisplay interface

[Robert Pluim]

>>>>> On Tue, 15 Oct 2019 21:32:25 -0300, Carlos Pita 
>>>>> <carlosjosepita@gmail.com> said:

    Carlos> I have updated my patch a bit:
    Carlos> 1. Instead of setting the new API to NULL when the scale factor is
    Carlos> ignored or unsupported by the backend, I'm setting it to a dummy
    Carlos> function returning 1. This keeps backwards compatibility and is more
    Carlos> convenient for the user of the interface.

    Carlos> 2. get_scale_factor now returns a double. Even though current scale
    Carlos> factors are integers, this is an interface that will better have to
    Carlos> make it through the forthcoming era of fractional scaling.

    Carlos> From 5b6e276e3dd9b4cb06bcf0e21e99227b2134a8bf Mon Sep 17 00:00:00 
2001
    Carlos> From: memeplex <carlosjosepita@gmail.com>
    Carlos> Date: Tue, 15 Oct 2019 19:14:03 -0300
    Carlos> Subject: [PATCH] Expose scale factor through the redisplay interface

    Carlos> * src/dispextern.h: add get_scale_factor API.
    Carlos> * src/xterm.c:
    Carlos>   - Unify usages of xg_get_scale and x_get_scale_factor into a
    Carlos>     consolidated x_get_scale_factor that is exported by the rif.
    Carlos>   - Simplify scale inferring logic (see note below).
    Carlos> * src/w32term.c:
    Carlos>   - Simplify w32_get_scale_factor in a similar way (see note).
    Carlos>   - Add it to the rif.
    Carlos> * src/nsterm.m:
    Carlos>   - Just add a dummy implementation that always return 1 to the rif,
    Carlos>     since there are no uses of any scale factor here.

This commit message doesnʼt use the ChangeLog format. There are
various help functions in vc for creating that in the correct
format. Either select some files, run 'vc-diff', and then
'diff-add-change-log-entries-other-window' (bound to C-x 4 A) to
prepare it, or, when youʼre committing, you can run C-c C-w, which
does the same.

    Carlos> Note 1: both x_get_scale_factor and w32_get_scale_factor computed
    Carlos> distinct scales for x and y by taking the ratio between effective
    Carlos> resolution in each direction and a standard 96 dpi resolution.  
Since
    Carlos> this ratio is then truncated to an integer (the floor) it seems to 
me
    Carlos> that there is no sensible possibility that these two numbers
    Carlos> diverge. Moreover, modern toolkits report one number as scale factor
    Carlos> and we need a common interface here. For those reasons I'm 
arbitrarily
    Carlos> picking the horizontal scale factor as THE scale factor.

Sure.

    Carlos> Note 2: I decided to let get_scale_factor return a double, even 
tough
    Carlos> factors currently in use are all integers AFAIK. This is in
    Carlos> anticipation of fractional scaling. I believe it's prudent to keep
    Carlos> the interface general in this regard.

Yes. I believe at least KDE already supports fractional scaling, Gnome
canʼt be far behind.

Carlos> diff --git a/src/dispextern.h b/src/dispextern.h
    Carlos> index 0615b16..b93e25f 100644
    Carlos> --- a/src/dispextern.h
    Carlos> +++ b/src/dispextern.h
    Carlos> @@ -2942,6 +2942,9 @@ reset_mouse_highlight (Mouse_HLInfo *hlinfo)
 
    Carlos>  #ifdef HAVE_WINDOW_SYSTEM
 
    Carlos> +  /* Return the scale factor for the screen containing frame F.  */
    Carlos> +  double (*get_scale_factor) (struct frame *f);
    Carlos> +
    Carlos>    /* Draw a fringe bitmap in window W of row ROW using parameters 
P.  */
    Carlos>    void (*draw_fringe_bitmap) (struct window *w, struct glyph_row 
*row,
    Carlos>                                struct draw_fringe_bitmap_params *p);
    Carlos> diff --git a/src/nsterm.m b/src/nsterm.m
    Carlos> index 5583c61..6e1b751 100644
    Carlos> --- a/src/nsterm.m
    Carlos> +++ b/src/nsterm.m
    Carlos> @@ -2957,6 +2957,11 @@ so some key presses (TAB) are swallowed by 
the system.  */
 
    Carlos>     
========================================================================== */
 
    Carlos> +static double
    Carlos> +ns_get_scale_factor (struct frame *f)
    Carlos> +{
    Carlos> +  return 1;  // TODO do we need to do something else here?
    Carlos> +}

As far as I know, macOS *can* scale displays, but generally doesnʼt. I
think using 1 here doesnʼt change anything from the status quo. There
is an API to get the scale factor if it turns out to be needed.

For the rest, it looks ok. Do you plan to make the changes to actually
use the rif interface as part of the same patch?

Robert