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.
We're not supposed to be redefining PACKAGE_VERSION, PACKAGE_...
from the configure generated confdefs.h. This patch rudely adds
paper over the problem. The compiler warnings are a problem for
us since our checking of various compiler flags assumes that
no news is good news, and that any warning messages are due
to the flags under test. The regression appears when using
an autoconf >= 2.64, at least, but not with 2.61.
The same issue appears in the pthread test because our conftest
unconditionally #defines _GNU_SOURCE, but autoconf ends up doing
that in the confdefs.h.
Use two levels of pthread support: a minimal level used to
build cairo itself, and a full level to build threaded apps
which want to use cairo. The minimal level tries to use
pthread stubs from libc if possible, but falls back to the
full level if that's not possible. We use CFLAGS=-D_REENTRANT
LIBS=-lpthread to find a real pthread library since that seems
to work on every unix-like test box we can get our hands on.
Introduce a new CAIRO_CC_TRY_LINK_WITH_ENV_SILENT macro for running
generic link tests with arbitrary CFLAGS/LIBS/LDFLAGS and no muttering
of autoconf messages. Rewrite the previous CAIRO_CC_TRY_FLAG in terms
of it.
This is an attempt to fix the broken situation we've been in where
automake links libcairo.la with c++ because it might potentially maybe
include C++ files.
Those potential files only exist in Chris' throwaway backends (skia, qt)
and the BeOS backend, so for 99.99% of cases, these backends are not
needed and linking with c++ is overkill. Also, no one wants to have
libcairo.so link to libstdc++.
This patch fixes that in mutliple steps:
1) Add build infrastructure to distinguish between C and C++ backends.
This is done by allowing to specify backend_sources as well as
backend_cxx_sources variables in Makefile.sources.
2) Optionally build a libcairo_cxx.la noinst library
This intermediate library is built for C++ backends only and therefor
linked using c++. It is then linked into the final libcairo.la. This
does not require c++, so the linking of libcairo.la is done with cc.
This also works around various weirdnesses that the current build system
exposes, where it assumes cisms when in fact using c++ semantics, like
not detecting c++ properly or:
https://bugzilla.redhat.com/show_bug.cgi?id=606523
This function is supposed to describe the backend in use. The describe
function is optional - and therefore initialized as NULL everywhere.
Note:
It is well known that the xlib backend uses X. What is not known is what
version the server supports or what graphics card it is running on. That
is the information the describe vfunc is supposed to provide.
I updated the Free Software Foundation address using the following script.
for i in $(git grep Temple | cut -d: -f1 )
do
sed -e 's/59 Temple Place[, -]* Suite 330, Boston, MA *02111-1307[, ]* USA/51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA/' -i "$i"
done
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=21356
... and fix the compile errors from it I get on my build.
It's Cairo style to put declarations before the code, so better warn
about it.
Besides, it eases porting to old compilers like MSVC.
