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

[Eli Zaretskii <eliz@gnu.org>]

> From: Carlos Pita <carlosjosepita@gmail.com>
> Date: Mon, 14 Oct 2019 20:42:59 -0300
> Cc: Alan Third <alan@idiocy.org>, Robert Pluim <rpluim@gmail.com>, 37689@debbugs.gnu.org
> 
> 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.

Adding them to frame redisplay interface would solve this.

> 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.

The code in init_fringe_bitmap obviously need some refactoring to rely
on redisplay interface.  You could make such refactoring part of the
job, or you could leave the current code intact and use its results.
I don't think I understand the difficulty of detecting row limits, but
you could begin by doing that for one platform, and then asking others
to do the same for other platforms.

> 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.

Couldn't we use the existing image-scaling code for that?  It is
implemented in each backend already.

> 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?

I don't think I understand what will stage (a) do under this proposal.
Stage (b) is already implemented, you just need to use it, and you
need to tell the transformation code the correct scale factor.