On Fri, 12 Oct 2012 09:47:47 +0200, Gerd Hoffmann kra...@redhat.com
wrote:
On 10/11/12 15:34, Jonathan Morton wrote:
On Thu, 11 Oct 2012 12:56:57 +0200, Gerd Hoffmann kra...@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.mor...@movial.com
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
