Spotted by Bastien Nocera. This was causing crashes in epiphany.

Pointed out by Daiki Ueno.

Since RENDER extension does not have support for using glyphs as
source, we bail out of the XRender-based implementation of
composite_glyphs when we find any color glyphs. The fallback
leads us to the mask compositor, whose glyphs() implementation
always uses an A8 maks for glyphs, so we have to bypass this
as well.

Since we don't have access to the glyphs loaded by the previous
compositor, we use the has_color_glyphs information of the font
to determine whether we can use the mask compositor.

Since pixman doesn't know how to render color glyphs and insists
on treating ARGB32 glyphs as having component alpha, we keep track
of whether we've seen any color glyphs while populating the pixman
glyph cache. If we do, use a slow-path function that knows how to
handle color glyphs.

The non-pixman-glyph-cache code path is using the same approach,
and the same slow-path function.

This information is available from the FT_Face using the
FT_HAS_COLOR macro. We cache the value in the unscaled_font
object as soon as we have an FT_Face.

This information will be used in subsequent commits to quickly
decide that we won't try to handle glpyhs as masks. Implementing
the new has_color_glyphs vfunc is optional - only backends that
support color glyphs need to implement it.

Use the FT_LOAD_COLOR flag to instruct freetype to load embedded
PNGs without converting them to grayscale. We always load both
the color and regular surface when we are loading surfaces.

With this, glyphs can have either a surface that is expected
to be used as mask, or a color_surface that should be used
as source, or both.

This will be used to support colored emoji glyphs that are
stored as PNG images in OpenType fonts.

This adds _cairo_atomic_int_get_relaxed and _cairo_atomic_int_set_relaxed which
are meant to have a behaviour of relaxed read/writes in C11's memory model. This
patch also uses these new function to fix a data race with freed_pool_t's |top|
data member.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=90318
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>

We need to link against libdrm to use its functions.

Signed-off-by: Enrico Weigelt, metux IT consult <enrico.weigelt@gr13.net>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>

Signed-off-by: Enrico Weigelt, metux IT consult <enrico.weigelt@gr13.net>

…es_intersect()

Signed-off-by: Enrico Weigelt, metux IT consult <enrico.weigelt@gr13.net>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>

These functions have been accidentially removed by commit:
494cfd7.

They're still needed by the DRM backend.
(will be used by subsequent patches)

Signed-off-by: Enrico Weigelt, metux IT consult <enrico.weigelt@gr13.net>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Cc: Uli Schlachter <psychon@znc.in>

Signed-off-by: Enrico Weigelt, metux IT consult <enrico.weigelt@gr13.net>

The releases page includes more than just cairo, so need to be explicit
in naming our uploaded Changelog file.

Looking back at past release announcements, it's been a long time since
we included the About Cairo bits.  This info is easily located on the
website and elsewhere, no need for the redundant data in the
announcement too.

The document uses X.Y.Z to sometimes mean the previous release version,
and in other places to mean the upcoming next release version.  Identify
these more explicitly.

Fixes:  https://bugs.freedesktop.org/show_bug.cgi?id=93152

http://lists.cairographics.org/archives/cairo/2015-November/026544.html

NextRequest is a macro that doesn't mix well with xcb, since
dpy->request is not updated. Instead use XNextRequest() that was fixed
to do the right thing with xcb in libX11 commit:
http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=7f8f9a36ef901f31279c385caf960a22daeb33fe

This may solve application X errors when a shmdt() is called by cairo
before the Attach request is processed.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>

This is broken since:

commit b1192be
Author: Adrian Johnson <ajohnson@redneon.com>
Date:   Mon Sep 21 21:35:05 2015 +0930

    Don't cull very thin lines on vector surfaces

    On vector surfaces, use a minimum line width when calculating extents.

    Bug 77298

Signed-off-by: Uli Schlachter <psychon@znc.in>