cairo-xlib semantics state that we copy the contents of a Window's
children when we use a Window as a source in a cairo operation. This
requires that we set the IncludeInferiors SubwindowMode on the GC.
However, we can only set one SubwindowMode for an operation and our
semantics are that drawing performed by cairo onto a Window are clipped
by its children (the ClipByChildren SubwindowMode). Therefore if we have
to copy between two Window, we can not use CopyArea. Furthermore, we
cannot tell if an external Drawable is a Window or a Pixmap, therefore
we treat all foriegn Drawables as Window.
Failure here means falling back to a render path, where we can
independently control the subwindow mode on the source and destination,
or to a GetImage/PutImage if the xserver does not support render.
Reported-by: Benjamin Otte <otte@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
None of the cairo clipping computations guarantee that the resulting
list of rectangles are constructed in any particular order. Promising
that they are results in an X error (BadMatch) which generally causes
applications to crash.
I suspect this may well be implicated in many (many) bug reports about
applications which use cairo.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Having spent the last dev cycle looking at how we could specialize the
compositors for various backends, we once again look for the
commonalities in order to reduce the duplication. In part this is
motivated by the idea that spans is a good interface for both the
existent GL backend and pixman, and so they deserve a dedicated
compositor. xcb/xlib target an identical rendering system and so they
should be using the same compositor, and it should be possible to run
that same compositor locally against pixman to generate reference tests.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
P.S. This brings massive upheaval (read breakage) I've tried delaying in
order to fix as many things as possible but now this one patch does far,
far, far too much. Apologies in advance for breaking your favourite
backend, but trust me in that the end result will be much better. :)
