| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
boilerplate/cairo-boilerplate-pdf.c | 4 ++++
boilerplate/cairo-boilerplate-ps.c | 4 ++++
boilerplate/cairo-boilerplate-svg.c | 4 ++++
build/configure.ac.system | 2 +-
4 files changed, 13 insertions(+), 1 deletions(-)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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>
|
|
I'm willing to make this a supported backend as I find it to be an
invaluable debugging tool...
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>
|
|
Autoconf 2.86 reports:
warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
|
|
Avoid ovverriding LINK, as it has a special meaning for the MSVC build
tools.
|
|
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'.
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=37388
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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>
|
|
|
|
|
|
Since 9f33f8453b4949cfdc63169d3acd7238f89379c2 tee is not compiled in
anymore by default. Reporting it as always enabled is misleading.
|
|
|
|
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.
|
|
Autodetect gobject and only use it if present.
Its absence is not to be considered a failure since it's not required.
|
|
This library is supposed to contain GType declarations for Cairo types.
It is also meant to support gobject-introspection binding creation.
|
|
We don't want to enable it by default when nobody uses it.
|
|
We don't want to enable it by default when nobody uses it.
|
|
Fix inline "dnl" strings left over from a string
substitution "--" -> "dnl".
|
|
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.
|
|
|
|
Missing a semicolon after pthread_cleanup_push. Incredibly
only openbsd 4.5 minded.
|
|
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.
|
|
Use CAIRO_CC_TRY_FLAG instead in the one place where we used
CAIRO_CC_TRY_LINK_FLAG and make the build system one macro
smaller.
|
|
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.
|
|
The recent commits to the build system changed a bunch of stuff in
there, so update the files.
|
|
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
|
|
They're unused, and less variables make the build system easier to
understand.
|
|
libtool should be fast by now
|
|
|
|
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.
|
|
|
|
own files.
|
|
|
|
|
|
Incorporate the pthread detection code from the autoconf archive. Should
fix build on obscure archs that pretend to be UNIXy - like Mac OS X
Tiger.
http://www.gnu.org/software/autoconf-archive/
http://www.gnu.org/software/autoconf-archive/ax_pthread.html
|
|
|
|
Catch up with changes in APIs, still no substance and the integration
with winsys handles needs review.
|
