bug#37689: Fringe pixmaps, widgets, etc. look ridiculously tiny in hidpi screen

[Carlos Pita <carlosjosepita@gmail.com>]

I'm finding non-trivial difficulties that make me think this is not
the best approach.

I've already mentioned one above:

1. I need the scaling factor in fringe.c yet it's not part of the
redisplay_interface. Functions that compute scaling factor are backend
specific and static.

Also:

2. init_fringe_bitmap does non-trivial manipulations to the original
bit sequence (nibble swapping, shifting, casting) to produce a
platform/backend-specific representation. redisplay_interface is
ill-defined in this regard, bitmap representation is not part of the
interface. For some backends init_fringe_bitmap even compresses shorts
to chars if width < 8, so I can't reliably detect row limits in a
platform/backend-agnostic way, which I need in order to scale the
bitmap.

3. The unsigned short representation is unfortunate. For 3x we need at
least int64_t. Then we need to modify all that backend-dependent
nibble swapping, shifting and casting that gives me the creeps.
Finally backends would have to be adapted to take an int64_t array as
input.

Given those considerable difficulties, I propose to scale bitmaps in
two stages instead:

a. At the level of fringe.c we only modify the geometry (width,
height) of the image, so that calculations that are independent of the
bitmap itself are correctly done. This way we can keep the unsigned
short representation, we don't need to touch that complex
platform/backend-dependent bit and we don't need to query the scaling
factor, thus solving points 1, 2 and 3 above.

b. Then each backend should set a transformation matrix or something
like that so that the bitmap is scaled to the appropriate resolution.
I already know how to do that for Cairo, it's trivial.

Eli, what do you think?