Comment 3 for bug 324854

The problem is that UXA's texture from pixmap doesn't do anything special to override the alpha channel to unity for 24 bit colour depth pixmaps on the X server. (The old TFP implementations did).

Having discussed this a bit with the Intel guys, it seems the consensus is that the required information should be tracked in the FBConfig of the GLXPixmap created to represent the X pixmap being mapped as a texture.

Unfortunately, the Intel (mesa) driver doesn't currently expose any 24bit colour depth visuals / FBconfigs, so we end up mapping a 32 bit depth texture, with undefined alpha channel state.

Since GL / Compiz is using textures with pre-multiplied alpha, if the alpha channel is zero (for example), the arithmetic assumption is that the R,G and B components have already been multiplied by this number - giving a transparent window. The background contents are then summed in, whcih will very likely max out the R, G and B channels - hence the white images you're seeing rather than transaprency.

This effect is only seen whilst animations are attempting to adjust the opacity of the window.. in other cases, Compiz switches off the blending functions, and thus the alpha channel of the texture doesn't affect the display.