Yet another reason window pictures suck

[Adam Jackson]

Context:

https://bugzilla.redhat.com/show_bug.cgi?id=533879

If you've got a 24bpp framebuffer, you poor misguided soul you, then you
have a conundrum.  Pixmaps are 32bpp but Windows aren't.  Suppose you
make a Picture out of a Window.  You would think you'd be required to
use one of the Formats with an associated Visual.  What does the spec
say about it?

QueryPictFormats
        The server responds with a list of supported PictFormats and
        a list of which PictFormat goes with each visual on each screen.
        Every PictFormat must match a supported depth, but not every
        PictFormat need have a matching visual.

...

CreatePicture
        This request creates a Picture object associated with the specified
        drawable and assigns the identifier pid to it.  Pixel data in the
        image are interpreted according to 'format'.  It is a Match error
        to specify a format with a different depth than the drawable.  If
        the drawable is a Window then the Red, Green and Blue masks must
        match those in the visual for the window else a Match error is
        generated.

So no, you don't actually have to pick a Visual Format for Window
Pictures.  You just have to pick a Format whose channels "match".  Which
means you can pick an [AX]8R8G8B8 Format, as long as the color channels
are the right way around.  We'll then dutifully smash the drawable's bpp
into the top 8 bits of the format code, so now you have a 24bpp
[AX]RGB32 picture.  Pixman will use the channel widths to compute pixel
width, and that won't match your storage, and it all goes quite shitty
from there.

So what do we do here?  I see two options:

a) Do something like fb24_32 to munge the format code on the way in and
out of Render operations on 24/24 windows, and (presumably) treat them
as though alpha=1.

b) Fix the spec to be more strict, and fix cairo and whoever else to be
more careful about picking Visual Formats for Window Pictures.

Both are doable?  I lean towards the latter, since we've been carrying
this bug for ~10 years and it's only now really showing up.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100521/c6402e77/attachment-0001.pgp>