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

[Carlos Pita]

> I'm not sure about this.  Admittedly, I'm not an expert on screen
> scales on GUI systems, but why do we need to drop the two scale
> factors as part of this change, which is basically just refactoring?
> I'd suggest to keep the 2 scale factors for now.  We can always
> replace 2 with one later.

I might do that, I might rename x/w32_get_scale_factor to
x/w32_get_scale_factor_xy and then define the rif exposed
x/w32_get_scale_factor to call these ones and simply drop the y scale
factor. But I would prefer not to do that because:

1. It adds complexity (more code, two different apis).

2. The only users of the (static) _xy variants would be x/w32_draw_underwave.

3. For me, it's hard to figure out why a screen would offer, say, x
resolution = 2 * 96dpi and y resolution = 3 * 96dpi (and surely we
could accommodate a humble underwave drawing routing if such a screen
happens to exist).

4. The nsterm backend also draws underwaves and doesn't use two
different scale factors (indeed, it doesn't use any scale factor at
all, nor the rest of this backend does).

5. AFAIK, the "toolkit industry" has long been using one number as THE
scale factor. Moreover, most of the time this number is just 1 or 2.

Regarding point 3, it's easier to imagine a screen with 1.99 and 2.01
x and y ratios that get respectively truncated down 1 and 2 x and y
scale factors. Now, the problem is not the different scale factors but
the way they were computed, and this is not solved at all by using 2
scale factors. Maybe we should use round instead of floor there.

I've modified the code comment and the message comment according to
your comments, Eli. I've also changed floor to round.

Best regards
--
Carlos

0001-Expose-scale-factor-through-the-redisplay-interface-.patch
Description: Text Data