[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#37770: [PATCH] Expose scale factor through the redisplay interface
From: |
Robert Pluim |
Subject: |
bug#37770: [PATCH] Expose scale factor through the redisplay interface |
Date: |
Wed, 16 Oct 2019 10:51:35 +0200 |
>>>>> 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
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/15
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/15
- bug#37770: [PATCH] Expose scale factor through the redisplay interface,
Robert Pluim <=
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/16
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/16
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Robert Pluim, 2019/10/17
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Eli Zaretskii, 2019/10/20
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/20
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/22
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Robert Pluim, 2019/10/24
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/24