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>
The X server accepts requests from client applications to create windows,
which are (normally rectangular) "virtual screens" that the client program
can draw into.
Windows are then composed on the actual screen by the X server
(or by a separate composite manager) as directed by the window manager,
which usually communicates with the user via graphical controls such as buttons
and draggable titlebars and borders.
As with other projects hosted on freedesktop.org, X.Org follows its
Code of Conduct, based on the Contributor Covenant. Please conduct
yourself in a respectful and civilized manner when using the above
mailing lists, bug trackers, etc: