The render specification says that the user's clip is applied to both
input and output. Other backends (eg. glamor and exa) clip the source
and mask via miComputeCompositeRegion. Instead, fb relies on pixman to
do all of the clipping, but pixman cannot clip the source unless we tell
it the clip that should be applied to the source.
fbComposite originally set the clip parameter of image_from_pict to TRUE
before commit a72c65e917 "fb: Adjust
transform or composite coordinates for pixman operations". That commit
talks about origin adjustments, but makes no mention of clipping, which
leads me to believe that the change from TRUE to FALSE was
unintentional. Unfortunately, we can't revert this small change because
the code now uses pCompositeClip, which is incorrect when there is a
transform applied.
I noticed this due to a massive performance regression when running
x11perf under marco (the window manager of the MATE desktop
environment). marco sets a clip on the source picture before calling
RenderComposite to update the screen, rather than the destination
picture.
Signed-off-by: Peter Harris <pharris@opentext.com>
ab0b853e75