[cairo] Pixel packing mismatch on XRender glyph rendering

[Matt Hoosier]

I'm working on an unreleased ARM product which has some acceleration
for the usual 2D operations (area copy, area fills, etc). The UI is a
Gtk+ program using the normal pangocairo text backend.

I've noticed that when the XRender glyph drawings commands arrive in
the X server (KDrive), the pixel format (8888, as nearly as I can
tell) of the source [glyph] surface doesn't match that of the target
(565) window. This causes a couple of undesirable effects:

* Our particular hardware unable to accelerate the blit of the glyphs
when the image format isn't identical, so we fall back to software
copying of the glyph.

* The software copy has to do a transformation between image formats,
further retarding performance.

I tried to trace this by inserting some breakpoints on
XRenderCompositeText{8,16,32}, and was surprised to see that
XRenderCompositeText8 is the variety which gets called on the client
side, rather than XRenderCompositeText16 to match the 565 pixel
packing on the X server's visuals.

Does anybody have a guess about why the glyph surfaces would be chosen
in a different image depth than the regular images?