[Pixman] image byte order?

[Jonathan Morton]

On Fri, 12 Oct 2012 09:47:47 +0200, Gerd Hoffmann <kraxel at redhat.com>
wrote:
> On 10/11/12 15:34, Jonathan Morton wrote:
> > On Thu, 11 Oct 2012 12:56:57 +0200, Gerd Hoffmann <kraxel at redhat.com>
> > wrote:
> >> How are the 32bpp image formats like PIXMAN_x8r8g8b8 defined to look
> >> like in memory?  Fixed format, i.e. always the same no matter whenever
> >> the box is big or little endian?  Or native endian?
> > 
> > Native endian.  The format is defined in terms of bitfields in a 32-bit
> > integer.
> 
> So PIXMAN_x8r8g8b8 @ bigendian box equals PIXMAN_b8g8r8x8 @ little
> endian box, correct?

Generally, yes.  And since most people use a little-endian box these
days, this can be confusing - since you would specify this to OpenGL as
GL_BYTE+GL_ARGB in both cases.

> > The 16-bit formats (such as r5g6b5) are also defined
> > similarly.
> 
> Ok.
> 
> > The 24-bit formats are not.
> 
> So PIXMAN_r8g8b8 has the red byte first no matter what the endian is,
> correct?

Yes.  This is potentially useful for subpixel antialiasing masks, BTW.

> > So to convert to or from a particular on-disk image format, or one
> > which is defined in terms of bytes (as OpenGL does), you could use
> > ntohl() and htonl() from the sockets subsystem.
> 
> Or pick the format depending on the machine byteorder when passing the
> pixel blob as-is to pixman_image_create_bits (well, for 32-bit formats
> at least, the 16-bit ones don't have a green bitfield any more when
> byteswapped ...).

That does also work, but only for formats which have all their fields 8
bits wide (which, admittedly, is very common).  That's why it doesn't
work for r5g6b5, for example.  An example of this in a 32-bit format
would be a2r10g10b10 which is associated with high-dynamic-range
monitors and rendering methods, or x14r6g6b6 which is used by some
mobile and embedded displays.

Note that OpenGL also treats these formats as word-based entities
rather than byte-based ones.

Another wrinkle is that compositing operations between different
formats are less likely to be well optimised than between images of the
same format.  You might therefore find that a one-time explicit
conversion still makes sense for performance reasons.

-- 
From: Jonathan Morton
      jonathan.morton at movial.com