Including sys/poll.h when poll.h is available produces a compile
warning on some systems, but only sys/poll.h is present on others
such as AIX. This makes sure the most suitable poll.h is included
in each situation.
Signed-off-by: George Matsumura <gmmatsumura01@bvsd.org>
This way all binutils tools are detected with $CHOST prefix
if exist. And strings is allowed to be substituted with
STRINGS environment override, so 'llvm-strings' (or other)
alternative can be used.
Bug: https://bugs.gentoo.org/726200
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Found via `codespell -i 3 -w -I ../cairo-word-whitelist.txt -L tim,ned,uint`
Follow up of 12cb59be7d
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
Run the command below suggested by geirha in ##sed@irc.freenode.net.
git grep -l 'http://.*freedesktop.org' | xargs sed -i 's|http\(://\([[:alnum:].-]*\.\)\{0,1\}freedesktop\.org\)|https\1|g'
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Run the command below suggested by geirha in ##sed@irc.freenode.net.
git grep -l 'http://.*cairographics.org' | xargs sed -i 's|http\(://\([[:alnum:].-]*\.\)\{0,1\}cairographics\.org\)|https\1|g'
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Fix distcheck by dropping use of the now-obsolete gtkdoc-mktmpl.
In preparation for the upcoming 1.16 release, I've made a few changes to
get distcheck to pass. I also updated it to run on Ubuntu 18.04, but
found that on newer distros distcheck won't run due to missing
gtkdoc-mktmpl, which has been deprecated upstream for some time. The
patch below disables everything that references it, and enables
distcheck to finish successfully.
Unfortunately, this probably regresses portions of our document
generation, and thus will need some reimplementation work. Anyone got
time to investigate a better solution for this?
Implement suggestion by Adrian Johnson to comment out skia in
configure.ac to avoid presenting it as an option to users. This was
discussed on the Cairo mailing list in September 2017.
Skia is not API stable and is not available in packaged+versioned forms,
resulting in it being a continually moving target. I.e. it's pretty
much always unusably out of date. The last update to the skia backend
was in 2014, and had not been updated very regularly prior to that.
We'll simply disable it for now. If no one complains by the next Cairo
snapshot release, we'll assume no one is needing it and will drop the
code entirely.
Meanwhile, if anyone does need it, it can be uncommented and used.
(The changes to the win32 build config appear to be automatically
generated as a result of disabling the feature in configure. I'm
committing them to avoid confusion.)
This improves the OpenGL ES support to extend it to version 3.0.
A number of new features are available in glesv3 including creation of
multi-sampled renderbuffers. These renderbuffers can be blitted to
single sample textures (but not the other way around). Other features
such as PBO for image uploading, are left as followon work.
For this preliminary implementation, glesv3 backends always create
renderbuffers, which can be set as single sample or multisample. The
renderbuffer's content is blitted to the texture only when used as a
source or a mask.
Images uploaded to a texture stay there until the surface is used as a
rendering target, at which point its painted to the renderbuffer.
This patch is heavily based off of Henry Song's initial GLESv3 patch
6f7f3795 from his cairogles fork of Cairo, and incorporates subsequent
fixes and pertinent refactorings from his trunk and review feedback from
Uli.
This implements the *functional* support for glesv3, excluding the
various optimization work to utilize its features. Rendering and
performance should not be expected to improve notably from pure glesv2.
As the GL backend for Cairo remains "experimental", these changes should
likewise be considered as such.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
On systems using GNU's strings implementation, 'strings -' causes a scan
of the whole file, which is equivalent to 'strings -a'. However, in
POSIX passing '-' as the first argument to 'strings' is declared
unspecified, and thus may break the build on systems that use a
different POSIX strings implementation.
Patch from Jung-uk Kim
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=88639
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
ARM has much weaker memory ordering guarantees than x86 by default, and
needs the memory barriers. A similar fix exists in the Skia codebase.
Fix suggested by Nathan Froyd.
Fixes: FDO #90302
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Acked-by: "Henry (Yu) Song" <henry.song@samsung.com>
There is an unintentional (benign) missing line continuation "\" in the
definition of MAYBE_WARN in configure. configure completes and issues a
WARNING:
configure: WARNING: cache variable cairo_cv_warn_maybe contains a
newline
Found and solved by Larry Baker.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=89750
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Even features which are disabled by default should appear in
cairo-features.h.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83359
(Patch approved by Behdad Esfahbod in bug tracker.)
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Recent versions of GCC/clang feature a new set of compiler intrinsics
for performing atomic operations, motivated by the operations needed to
support the C++11 memory model. These intrinsics are more flexible than
the old __sync_* intrinstics and offer efficient support for atomic load
and store operations.
Having the load appear atomic to the compiler is particular important
for tools like ThreadSanitizer so they don't report false positives on
memory operations that we intend to be atomic.
Patch from Nathan Froyd <froydnj@mozilla.com>
When using clang -O4, the compiled test object is output in bitcode
format rather than as an ELF object, so when we grep the test value from
the object it fails. To work around this, go ahead and link the test
object into an executable, and then grep against this native binary
instead of the compiler's intermediary object.
We need to add __attribute__((used)) to ensure the d variable doesn't
get optimized out during linking, since it's not referenced in the
test's main().
Patch authored by cmuelle8 <abendstund@gmail.com>
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63310
This patch fixes majorly 2 kinds of warning issues:
(1)
cc1plus: warning: command line option '-Wold-style-definition' is valid for Ada/C/ObjC but not for C++ [enabled by default]
cc1plus: warning: command line option '-Wdeclaration-after-statement' is valid for C/ObjC but not for C++ [enabled by default]
cc1plus: warning: command line option '-Wnested-externs' is valid for C/ObjC but not for C++ [enabled by default]
cc1plus: warning: command line option '-Wstrict-prototypes' is valid for Ada/C/ObjC but not for C++ [enabled by default]
cc1plus: warning: command line option '-Wmissing-prototypes' is valid for Ada/C/ObjC but not for C++ [enabled by default]
cc1plus: warning: command line option '-Wbad-function-cast' is valid for C/ObjC but not for C++ [enabled by default]
Solution: Enable these warnings only for C compiler and not for C++
(2)
cairo-qt-surface.cpp: In function 'cairo_int_status_t _cairo_qt_surface_fill(void*, cairo_operator_t, const cairo_pattern_t*, const cairo_path_fixed_t*, cairo_fill_rule_t, double, cairo_antialias_t, const cairo_clip_t*)':
cairo-qt-surface.cpp:852:5: warning: inlining failed in call to 'PatternToBrushConverter::PatternToBrushConverter(const cairo_pattern_t*)': --param max-inline-insns-single limit reached [-Winline]
cairo-qt-surface.cpp:1339:38: warning: called from here [-Winline]
cairo-qt-surface.cpp:390:1: warning: inlining failed in call to 'QPainterPath _ZL10path_to_qtPK17_cairo_path_fixedPK13_cairo_matrix.part.13()': call is unlikely and code size would grow [-Winline]
cairo-qt-surface.cpp:1306:1: warning: called from here [-Winline]
cairo-qt-surface.cpp:1051:5: warning: inlining failed in call to 'PatternToBrushConverter::~PatternToBrushConverter()': call is unlikely and code size would grow [-Winline]
Solution: Add __attribute__ ((noinline)) to the function as mentioned in
http://stackoverflow.com/questions/11724235/warning-for-template-with-g-o2-or-os-o-o1 (Edit 3)
Signed-off-by: Ravi Nanjundappa <nravi.n@samsung.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
This just never worked too well and caused too many issues. I don't think anyone
will miss this.
As mentioned in the below bug report, proper LTO support also requires using
special versions of ranlib, nm and ar which support the LTO object files.
Otherwise, calling the normal ranlib on an .a library breaks the list of
exported symbols and thus completely breaks the static library.
This (partly) reverts the following commits:
c3645d97eb configure.ac: Add a --disable-lto configure option
d486ea30f1 configure: Conditionally include -flto
0870c6fb5b gcc-4.5 warnings and optimisation flags.
(The last commit is the one which brought us -flto in the first place even
though it doesn't talk about this. It's also the one which is only reverted
partly.)
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=77060
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Uli Schlachter <psychon@znc.in>
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
Link-Time Optimization seems to be stable enough with gcc 4.8 and 4.9,
but has proven to be an issue in the past for many cairo users (webkit,
efl, ubuntu, opensuse, gentoo, arch...) who carry patches to disable it.
Gentoo's patch[1] adds a --disable-lto option to leave it enabled by
default but give users the ability to work around lto related build
problems (c.f. fdo #77060). Patch appears to have been authored by
Alexandre Rostovtsev[2].
1: sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/cairo/files/cairo-1.12.16-lto-optional.patch
2: https://bugs.gentoo.org/show_bug.cgi?id=509552
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=60852
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
Reviewed-by: Uli Schlachter <psychon@znc.in>
gcc-4.4 and later accept every -Wno option. So we can test for the
option without no in the name to check if the option is supported.
Each time a warning is emitted and without this fix, on gcc-4.4 that will
add this warning:
cc1: warning: unrecognized command line option "-Wno-unused-but-set-variable"
bugs.freedesktop.org #51633, rediffed after 1.12.4
Of course this assumes that all compilers will behave like gcc, which is
reasonably implicit in the set of warning flags.
Signed-off-by: Gilles Espinasse <g.esp@free.fr>
[ickle: slight modification to test both -W and -Wno variants to ideally
preserve compatability with non-GCC compilers sharing GCC options!]
Inside PKG_CHECK_MODULES, AC_MSG_RESULT(no) is already displayed, so the
caller should not use another AC_MSG_RESULT(no).
Add a comment that empty ACTION-IF-NOT-FOUND is not allowed for
PKG_CHECK_MODULES, but a simple : is enough.
This is bugs.freedesktop.org #51628, rediffed after 1.12.4
Signed-off-by: Gilles Espinasse <g.esp@free.fr>
'how to allow undefined symbols in shared libraries' test should use CAIRO_CC_TRY_FLAG_SILENT or configure display is a bit out of order like this
checking how to allow undefined symbols in shared libraries used by test suite... checking whether gcc supports -Wl,--allow-shlib-undefined... yes
-Wl,--allow-shlib-undefined
Signed-off-by: Gilles Espinasse <g.esp@free.fr>
Signed-off-by: Uli Schlachter <psychon@znc.in>
The Makefile.win32 in the subdirectories provide a working 'clean'
target (defined in Makefile.win32.common), the central Makefile.win32
'clean' target does not do anything.
Replace the noop 'clean' target with one that cleans all the subdirs.
The Makefile.win32 build system assumes that the files are in the same
directory level. If this is not the case, the compiler fails when it
tries to write the object files to a non-existing directory.
This can be fixed simply by making sure that the destination directory
always exists.
Fixes:
fatal error C1083: Cannot open compiler generated file:
'release/win32/cairo-win32-debug.obj': No such file or directory
This adds a new GPU accelerated backend for Cairo based on the Cogl 3D
graphics API.
This backend aims to support Cairo in a way that translates as naturally
as possible to using a GPU, it does not strive to compete with the
anti-aliasing quality of the image backend if it can't be done
efficiently using the GPU - raw performance isn't the only metric of
concern, so is power usage.
As an overview of how the backend works:
- fills are handled by tessellating paths into triangles
- the backend has an extra fill_rectangle drawing operation so we have
a fast-path for drawing rectangles which are so common.
- strokes are also tessellated into triangles.
- stroke and fill tessellations are cached to avoid the cpu overhead
of tessellation and cost of upload given that its common for apps to
re-draw the same path multiple times. The tessellations can survive
translations and rotations increasing the probability that they can be
re-used.
- sources and masks are handled using multi-texturing.
- clipping is handled with a scissor and the stencil buffer which
we're careful to only update when they really change.
- linear gradients are rendered to a 1d texture using a triangle
strip + interpolating color attributes. All cairo extend modes
are handled by corresponding texture sampler wrap modes without
needing programmable fragment processing.
- antialiasing should be handled using Cogl's multisampling API
XXX: This is a work in progress!!
TODO:
- handle at least basic radial gradients (No need to handle full
pdf semantics, since css, svg and canvas only allow radial gradients
defined as one circle + a point that must lie within the first
circle.) - currently we fall back to pixman for radial gradients.
- support glyph rendering with a decent glyph cache design. The
current plan is a per scaled-font growable cache texture + a
scratch cache for one-shot/short-lived glyphs.
- decide how to handle npot textures when lacking hardware support.
Current plan is to add a transparent border to npot textures and use
CLAMP_TO_EDGE for the default EXTEND_NONE semantics. For anything else
we can allocate a shadow npot texture and scale the original to fit
that so we can map extend modes to texture sampler modes.
The cairo-missing library provides the functions which are needed in
order to correctly compile cairo (or its utilities) and which were not
found during configuration.
Fixes the build on MacOS X Lion, which failed because of collisons
between the cairo internal getline and strndup and those in libc:
cairo-analyse-trace.c:282: error: static declaration of ‘getline’ follows non-static declaration
/usr/include/stdio.h:449: error: previous declaration of ‘getline’ was here
cairo-analyse-trace.c:307: error: static declaration of ‘strndup’ follows non-static declaration
...
Add the cairo_time_t type (currently based on cairo_uint64_t) and use
it in cairo-observer and in the perf suite.
Fixes the build on MacOS X (for the src/ subdir) and Win32, whch
failed because they don't provide clock_gettime:
cairo-surface-observer.c:629: error: implicit declaration of function 'clock_gettime'
cairo-surface-observer.c:629: warning: nested extern declaration of 'clock_gettime'
cairo-surface-observer.c:629: error: 'CLOCK_MONOTONIC' undeclared (first use in this function)
...
The mime surface is a user-callback surface designed for interfacing
cairo with an opaque data source. For instance, in a web browser, the
incoming page may be laid out and rendered to a recording surface before
all the image data has finished being downloaded. In this circumstance
we need to pass a place holder to cairo and to supply the image data
later upon demand.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Another logging passthrough surface that records the style of operations
performed trying to categorise what is slow/fast/important.
In combination with perf/cairo-analyse-trace it is very useful for
understanding what a trace does. The next steps for this tool would be
to identify the slow operations that the trace does. Baby steps.
This should be generally useful in similar situations outside of perf/
and should be extensible to become an online performance probe.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I forgot to proof-read the patch before pushing and forgot I had left in
some damage from trying to get skia to link using libtool.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Still hopelessly broken. Requires compiling cairo to use static linking
and then still requires manual linkage to workaround libtool. Lots of
functionality is still absent - we need to either find analogues to some
Cairo operations or implement fallbacks - but it is sufficient to
investigate how Skia functions in direct comparison with Cairo for
tessellation/rasterisation.
Caveat emptor.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The build system does not honor the flags set externally and replaces
it with the pthread-only flags when detecting pthread
availability. This breaks the configuration of cairo in some
cross-compilation environments:
conftest.c:1: note: someone does not honour COPTS correctly, passed 0 times
The test for pthread should append the new flags to the old one.
The experiment was at best a pyrrhic victory. Whilst it did show that
you could successfully subvert cairo_xcb_surface_t and provide the
rendering locally faster (than the xlib driver at that time), any
performance benefits were lost in the synchronisation overheads and
server-side buffer allocation.
Once cairo-gl is mature, we need to look at how we can overcome these to
improve client-side rendering
In the meantime, cairo-xcb is no longer my playground for
experimentation and is shaping up to become a stable backend...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I've since incorporated (nearly) all the features from cairo-drm into
xf86-video-intel, making this experiment defunct.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
