PNG load/save swaps RGBA channels on big-endian
GTK 4.6.0 fails lots of tests on Debian s390x, including testsuite/gdk/memorytexture.c
. I spent some time debugging this and found that the TEXTURE_METHOD_PNG_PIXBUF
tests were failing.
It looks as though 8-bit textures were given to libpng in RGB or RGBA order on little-endian machines, but in ABGR or BGR order on BE (similar to CAIRO_FORMAT_ARGB32
, which always has the alpha in the most significant bits of a 32-bit word, and the blue in the least significant). However, it looks as though libpng actually wants something more like GTK's GDK_MEMORY_R8G8B8A8
or GDK_MEMORY_R8G8B8
, with the first byte of the buffer always being a red channel, regardless of whether the machine's endianness would interpret that as the most or least significant bits of a 32-bit word.
16-bit textures seem to be correct for libpng's expectations, with the first 16-bit unit consistently being a red channel.
Lots of reftests also failed, but I'm hoping this was because they used PNG files that were getting byteswapped. If fixing the PNG load/save doesn't also fix the reftests, I'll treat reftest failures as a separate issue.
TEXTURE_METHOD_TIFF_PIXBUF
was also affected by this, because it's effectively a copy of TEXTURE_METHOD_PNG_PIXBUF
due to #4615 (closed).