Fixes the race condition when one thread uses cairo_mask_compositor_t
pointer returned by _cairo_image_mask_compositor_get, while another one
started but has not finished it's initialisation yet
Usage:
static cairo_atomic_once_t once = CAIRO_ATOMIC_ONCE_INIT;
if (_cairo_atomic_init_once_enter(&once)) {
/* Initialization code */
_cairo_atomic_init_once_leave(&once);
}
https://bugs.freedesktop.org/show_bug.cgi?id=103037
New implementations of _cairo_pattern_sampled_area and _cairo_pattern_get_extents
which produce a more accurate bounding box. These do not depend on side-effects
of analyze_filter, can handle different horizontal and vertical scales, filters
wider than 1 for down-scaling, and compute a somewhat tighter bounding box
in most cases.
I removed the pad output of _cairo_pattern_analyze_filter as it is unused.
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
Remember to check for a supported render version before making a
FillRectangle request, and fallback to the core protocol where possible
instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
Currently we perform the conversion using XPutPixel which is hideously
slow and so it is faster to create a new surface that matches the
format correctly, upload and allow X to perform the conversion. In other
words disable the "fast" path for format mismatches.
Based on a patch by Ginn Chen <ginn.chen@oracle.com>
Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=716462
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. :)
