/cc @nigeltao

Note that @nigeltao is not working at the moment so you may wait a while for a response. He's definitely the person to respond to this, though.

Thank you for the heads up, @adg. I hope he's okay.

@stephenwithav he's fine. :-)

I think it's a mistake to add every possible pixel layout to package image. Leaving for @nigeltao.

Yeah, we added an image.RGB type (without the 'A') in the 1.3 or 1.4 cycle, and rolled it back because it complicated the other image/* libraries too much. Similarly, I don't think we want an image.BGRA type.

In hindsight, it might have been more efficient for interop with other C libraries if the standard type was image.BGRA instead of image.RGBA. On the other hand, the PNG order is RGBA. In any case, that horse has bolted.

For an alternative approach to dealing with BGRA interop (e.g. X11, and presumably cairo uses the same byte order), grep for "swizzle" under golang.org/x/exp/shiny/driver.

Thank you for the explanation, @nigeltao. And for pointing out swizzle--I hadn't realized that Go supported assembly via cgo.

cairo doesn't support BGRA, unfortunately; fortunately, adding ARGB support via an external package wasn't too difficult.

I'll polish that code and push it in the next week or two, then add a link here in case anyone needs it in the future.

Assembly isn't cgo. It's assembly. :-)

As for cairo, CAIRO_FORMAT_ARGB32 (for little-endian CPUs) is what Go (and Go's swizzle) calls BGRA. The cairo naming convention is most significant bytes to least significant bytes, and is endian-ness dependent. The Go naming convention is in memory order, and is endian-ness independent. For little-endian CPUs, cairo's least significant byte (blue) comes first, so they're the same, and the world seems to have settled on little-endian, for better or worse.