bug#37932: [PATCH] Support hidpi fringes and images with Cairo

[Carlos Pita]

> If I read the patch correctly, you now auto-scale inside image.c,
> which shouldn't change anything when not using :scale. What's the

Right, AFAICS scaling of images was always done inside image.c, that's
where transformation routines are coded. The difference is more in the
usage of the :scale parameter. Previously there were two cases:

1. The caller doesn't pass a :scale in the spec. Then a :scale
property compensating for the dpi of the screen is automatically added
to the spec if the image-scaling-factor customization option is set to
'auto.  The computed scale factor assumes a representative character
to be 10px width.

2. The caller passes a :scale in the spec. Then the image is scaled
using this number and no extra dpi-adapting-scaling is done.

I see two shortcomings with this approach:

a. One I've already mentioned above: scaling required by the
application shouldn't interfere with scaling done to fit screen
resolution, which is a concern at a very different level.

b. Moreover, I'm not sure how compatible is this 10px char width
assumption with the 96dpi base resolution assumed to compute scale
factors in xterm.c and w32term.c. OTOH, the 96dpi assumption is
compatible with what gtk does. Anyway, with my patch each platform is
able to set a different base resolution if that's necessary.

> effect when code passes in eg :scale 2? Autoscaling + frame scaling,
> so for a frame where scale == 2 we get * 4? I guess that would be
> sensible, but weʼd need to explain it clearly. [1]

User code should be mostly unaware of the underlying resolution except
for very specialized cases. Currently, that is reflected in the
default 'auto image-scaling-factor. It's true that, as I commented in
point 1 above, nowadays one can pass a explicit :scale in order to
turn auto-scaling off, although in most cases that would probably
introduce a bug by *inadvertently* turning auto-scaling off. We can
add another property to the spec in order to enforce real pixel size,
or the user can divide the desired scale by the result of
image-compute-scaling-factor (in the same way the xterm backend is
circumventing gtk auto-scaling by applying the inverse scale operation
first). I prefer adding a new spec property to turn-off auto-scaling,
because that way both image-compute-scaling-factor and
image-scaling-factor could be removed from the codebase and also the
inconsistency between 96dpi and 10px criteria wouldn't be a problem
any more.