SkColorType vs GrPixelConfig vs any other RGBA_8888 style names

[Nigel Tao]

https://github.com/afrantzis/pixel-format-guide is a tool that takes OpenGL, Vulkan, SDL, Wayland, etc. pixel format names like WL_DRM_FORMAT_ARGB8888 and prints e.g. whether "ARGB" or "BGRA" gives the order in memory order or in "uint32 high to low value" order, the point being that endianness makes the two diverge. The tool is there because, while each individual system like OpenGL is consistent within itself, different systems pick different semantics.

https://github.com/afrantzis/pixel-format-guide/issues/1 is a feature request to add the Skia pixel format names. The maintainer asks, "A quick look at skia shows that it has a couple of pixel format definitions: SkColorType and GrPixelConfig. Are there any others formats in skia that would be interesting to document?"

I'm not actually intimately familiar with Skia (or with the pixel-format-guide). Could somebody who knows Skia well answer that question on the github issue?

Thanks.

[Mike Klein]

Hope this doesn't scare you off, but

• kRGB_565_SkColorType  is stored 15| rrrrr gggggg bbbbb |0, and
  
• kRGBA_8888_SkColorType is stored 32| aaaaaaaa bbbbbbbb gggggggg rrrrrrrr |0,

....we're not even self-consistent.

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To post to this group, send email to skia-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/skia-discuss.
For more options, visit https://groups.google.com/d/optout.

[Nigel Tao]

On Thursday, September 14, 2017 at 11:04:51 AM UTC+10, Mike Klein wrote:

Hope this doesn't scare you off, but

• kRGB_565_SkColorType  is stored 15| rrrrr gggggg bbbbb |0, and
  
• kRGBA_8888_SkColorType is stored 32| aaaaaaaa bbbbbbbb gggggggg rrrrrrrr |0,

OK, when you say stored 32|...|0, are you talking about in memory order (bytes in RAM) or in "uint32 high to low value" order (values in registers)?

They are the same for big endian but opposite for little endian. Sorry to tell you what you already know, but the goal here is complete unambiguity.

....we're not even self-consistent.

Heh, indeed, I see that in e.g. src/core/SkColorSpaceXformPriv.h, the select_xform_format function in, kRGBA_8888_SkColorType maps to SkColorSpaceXform::kRGBA_8888_ColorFormat (RGBA to RGBA), but kRGB_565_SkColorType maps to SkColorSpaceXform::kBGR_565_ColorFormat (RGB to BGR). I suppose that simply adds importance to the pixel-format-guide tool...

FWIW, SkImageInfo.h has a "SHFIT" typo in "SK_*32_SHFIT".

[Mike Klein]

Oh definitely everything little endian.  We have only vestigial support for anything big-endian.  It's completely untested and mostly ignored.

So, if you're walking through a kRGBA_8888_SkColorType buffer byte by byte, you'll first hit a byte holding red, then green, then blue, and fourth alpha.  Walking through a "kRGB_565_SkColorType" buffer byte by byte, you'll first hit a byte holding blue and some green, then the rest of green and red.  If you load kRGBA_8888_SkColorType in a little-endian uint32_t x, (x & 1) is the significant red bit; loading kRGB_565_SkColorType as uint16_t y, (y & 1) is the least-significant blue bit.

I suspect that whoever wrote the SkColorSpaceXform::ColorFormat enum decided to fix this little inconsistency by adding a new inconsistency.  :)

--

[Nigel Tao]

On Friday, September 15, 2017 at 10:34:53 AM UTC+10, Mike Klein wrote:

Oh definitely everything little endian.  We have only vestigial support for anything big-endian.  It's completely untested and mostly ignored.

So, if you're walking through a kRGBA_8888_SkColorType buffer byte by byte, you'll first hit a byte holding red, then green, then blue, and fourth alpha.  Walking through a "kRGB_565_SkColorType" buffer byte by byte, you'll first hit a byte holding blue and some green, then the rest of green and red.  If you load kRGBA_8888_SkColorType in a little-endian uint32_t x, (x & 1) is the significant red bit; loading kRGB_565_SkColorType as uint16_t y, (y & 1) is the least-significant blue bit.

It's still not clear to me whether kRGBA_8888_SkColorType is defined in terms of native order or in memory order.

Sure, for little endian, opaque blue is 0xFFFF0000 as a native uint32 and {0x00, 0x00, 0xFF, 0xFF} in memory.

You say that big-endian support is untested, but in theory, what would you expect kRGBA_8888_SkColorType's opaque blue to be on big-endian?

If the color type is defined in terms of native order (i.e. endianness does not affect native order), it'd be 0xFFFF0000 as native and {0xFF, 0xFF, 0x00, 0x00} in memory.

If the color type is defined in terms of memory order  (i.e. endianness does not affect memory order), it'd be 0x0000FFFF as native and {0x00, 0x00, 0xFF, 0xFF} in memory.

Sorry to be stubborn, but the goal here is complete unambiguity.

[Mike Klein]

kRGBA is named RGBA because the bytes are stored in memory in r-g-b-a order.

But let's also just double-down and say Skia doesn't support big-endian machines.

--