bug#38109: Updated Emacs to HEAD, consistently not scaling now

[Alan Third <alan@idiocy.org>]

On Thu, Nov 07, 2019 at 11:12:31PM +0100, Adam Sjøgren via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
> Lars writes:
> 
> > I made two PNGs from wry.xpm. 
> >
> > file /tmp/wry*.png 
> > /tmp/wry2.png: PNG image data, 13 x 14, 8-bit/color RGBA, non-interlaced
> > /tmp/wry.png:  PNG image data, 13 x 14, 2-bit colormap, non-interlaced
> >
> > With the colormap png, I see the same as you -- no scaling, but a large
> > canvas.  With the non-colormap one, I get the proper scaling, too.
> 
> Interesting; the files I tested with:
> 
>   $ file wry.*
>   wry.gif: GIF image data, version 89a, 16 x 16
>   wry.png: PNG image data, 16 x 16, 4-bit colormap, non-interlaced
> 
> So that's consistent with what you see. Perhaps testing was done with
> RGB(A) images, and not with colormaps/palettes.

OK, that makes sense. Check out the comment and code at line 2593 of
image.c:

    /* FIXME: Do we need to handle all possible bit depths?
       XRenderFindStandardFormat supports PictStandardARGB32,
       PictStandardRGB24, PictStandardA8, PictStandardA4,
       PictStandardA1, and PictStandardNUM (what is this?!).
    
       XRenderFindFormat may support more, but I don't
       understand the documentation.  */
    format = XRenderFindStandardFormat (display,
                                        depth == 32 ? PictStandardARGB32
                                        : depth == 24 ? PictStandardRGB24
                                        : PictStandardA8);
    *picture = XRenderCreatePicture (display, *pixmap, format, 0, &attr);

There should be an error message somewhere telling you that Emacs
doesn’t support scaling with that bit depth.

I guess it should be simple enough to add 4 and 1 bit to the above
which I hope would cover some of the above cases...
-- 
Alan Third