[cairo-bugs] [Bug 43158] Does not hold to requested or stated pixel formats

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=43158

--- Comment #3 from Andrea Canciani <ranma42 at gmail.com> 2011-11-22 18:22:45 PST ---
(In reply to comment #2)
> Right, sure. My mistake. I didn't notice the note in the docs about endianness.
> I made the mistake of thinking that the pixel format description on its own was
> sufficient to describing the way pixels are formatted in memory. </passive
> aggression>

RGB24 is even less self-explaining in that respect (most people believes that
it indicates that pixels only occupy 3 bytes).

FWIW even cairo devs sometimes have to deal with the endianness/word-based
access issue (you can have a look at the endian-dependent code in cairo-gl, for
example).
The choice of making the pixels accessible using "pixelsize-words" was probably
made to keep the access to non-byte-aligned formats simpler (accessing R5G6B5
would get quite ugly).

> 
> My problem originally arose when I was trying to transfer an imageSurface to an
> external library, cogl. Cogl's format description scheme for the most part took
> the seemingly[to me] more logical avenue of describing the pixel formats in
> terms of byte order. The fact that these format descriptions don't align very
> well with cairo seems to be indicative of a bastard of a situation to me.

You might want to keep an eye on cairo-gl (which already accesses/maps many
"byte-defined" formats as cairo formats and on the new cogl backend.

If you have any idea about improvements to the documentations that might help
avoid (to other people) your same issue (being tricked by misleading/not
self-explaining format names), they would be very appreciated.
Changing format names or meaning would be an API break, so it's not possible
(although for cairo 2.x I would definitely vote for deprecating RGB24 in favor
of something which explicitly states that the format has 32 bpp).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.