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>
All of the build depends on cairo-features.h. By having a target to
generate it that can be run from anywhere, it is possible to delegate
the dependency handling to 'make'.
Caching is fragile sinle the enable commands cannot have any side-effects
when caching. And doesn't have significant speedup at this level. Just
remove it.
cairo-trace already depended upon HAVE_FUNLOCKFILE for its
thread-safety.
[This is a candidate for 1.10.]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Add NONPKGCONFIG_EXTRA_LIBS that are only put into the generated pc file
but not used when linking. This is now used to add -lcairo-gobject to
the cairo-gobject.pc file.
The code was testing the output variable $use_pthread rather than
the input variable $enable_pthread when checking that pthreads
were actually found when requested.
