Compiz shadow breakage related to pixman

[Robert Carr]

On 6/1/07, Michel Dänzer <michel at tungstengraphics.com> wrote:
> On Fri, 2007-06-01 at 16:53 +0200, Soeren Sandmann wrote:
> > 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.
>
> I didn't notice any other issues before or after that.
>
> > 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.
>
> AFAICT gtk-window-decorator uses Cairo to draw the shadows, so I'm not
> sure how to determine that. Any guidance would be appreciated.

I don't have a machine to reproduce this on, but to make this easier:

It uses compiz libdecoration which in turn uses XRender directly. All
of the involved formats are ARGB32.

The function is decor_shadow_create in compiz/libdecoration/decoration.c


There are three composite operations, all use FilterConvolution and PictOpSrc.