Compiz shadow breakage related to pixman

[Soeren Sandmann]

Michel Dänzer <michel at tungstengraphics.com> writes:

> With current xserver master on my PowerBook, the shadows drawn by compiz
> (well, really gtk-window-decorator) have a hard edge instead of being
> soft as intended. See the attached image.
> 
> As far as I've been able to determine[0] this was introduced with commit
> c5ef84c325440af5fbdf9f44c3781d99a0392df9 ('Make the general compositing
> code create a pixman image and call pixman_image_composite().').
> 
> Since nobody else has reported this I'll assume it's platform specific.
> The two usual suspects would be endianness and char being unsigned by
> default. When I get time, I could try building pixman with -fsigned-char
> to test for the latter. Let me know if there's anything else I can do to
> narrow this down further.

Note that pixman didn't have any endianness detection until pixman
commit e32b240145ee7bbc2e69020b0bb00c33c68acf15 on May 22nd. So any
pixman older than that should be expected to be broken on ppc.

If this really is platform specific, then information about the
composite operation and the depths and formats of the drawables
involved would be necessary since I don't have any big-endian or
unsigned-char platforms to test on. I'll try and get a system set up
with compiz to see if I can reproduce.

> [0] Bisecting this was a pain because older xserver commits tend not to
> work with newer pixman commits. Until an ABI is maintained for pixman,
> it might make sense to keep it in the xserver tree.

I agree this is painful. I am not ready to maintain ABI yet, but close
enough that I don't think moving it into the xserver tree at this
point is worth it. The main ABI breakage I expect is that the
pixman_format_code_t enum will change so that it can support formats
with > 16 bit per component.



Soren