Use the DRM interface to h/w accelerate composition on image surfaces.
The purpose of the backend is simply to explore what such a hardware
interface might look like and what benefits we might expect. The
use case that might justify writing such custom backends are embedded
devices running a drm compositor like wayland - which would, for example,
allow one to write applications that seamlessly integrated accelerated,
dynamic, high quality 2D graphics using Cairo with advanced interaction
(e.g. smooth animations in the UI) driven by a clutter framework...
In this first step we introduce the fundamental wrapping of GEM for intel
and radeon chipsets, and, for comparison, gallium. No acceleration, all
we do is use buffer objects (that is use the kernel memory manager) to
allocate images and simply use the fallback mechanism. This provides a
suitable base to start writing chip specific drivers.
Based on the work by Øyvind Kolås and Pierre Tardy -- many thanks to
Pierre for pushing this backend for inclusion as well as testing and
reviewing my initial patch. And many more thanks to pippin for writing the
backend in the first place!
Hacked and chopped by myself into a suitable basis for a backend. Quite a
few issues remain open, but would seem to be ready for testing on suitable
hardware.
The meta-surface is a vital tool to record a trace of drawing commands
in-memory. As such it is used throughout cairo.
The value of such a surface is immediately obvious and should be
applicable for many applications. The first such case is by
cairo-test-trace which wants to record the entire graph of drawing commands
that affect a surface in the event of a failure.
Written by Vladimir Vukicevic to enable integration with Qt embedded
devices, this backend allows cairo code to target QPainter, and use
it as a source for other cairo backends.
This imports the sources from mozilla-central:
http://mxr.mozilla.org/mozilla-central/find?text=&kind=text&string=cairo-qpainter
renames them from cairo-qpainter to cairo-qt, and integrates the patch
by Oleg Romashin:
https://bugs.freedesktop.org/attachment.cgi?id=18953
And then attempts to restore 'make check' to full functionality.
However:
- C++ does not play well with the PLT symbol hiding, and leaks into the
global namespace. 'make check' fails at check-plt.sh
- Qt embeds a GUI into QApplication which it requires to construct any
QPainter drawable, i.e. used by the boilerplate to create a cairo-qt
surface, and this leaks fonts (cairo-ft-fonts no less) causing assertion
failures that all cairo objects are accounted for upon destruction.
[Updated by Chris Wilson]
Acked-by: Jeff Muizelaar <jeff@infidigm.net>
Acked-by: Carl Worth <cworth@cworth.org>
Felt like pulling the latest stuff, since I branched back in February.
Conflicts:
build/configure.ac.features
src/cairo.h
util/cairo-script/csi-replay.c
Adds a new, fake, fontconfig font backend. Fontconfig can be disabled
using --disable-fc, in which case the toy text API wont find fonts and
the internal font will always be used.
Also defines the feature macro CAIRO_HAS_FC_FONT. The two fontconfig-specific
functions in cairo-ft.h depend on that macro now.
It doesn't work for non GCC compiler right now, as "-Werror -Wall" is
an error to non GCC compiler.
I swapped the sequence of build/configure.ac.system and build/
configure.ac.warnings, then WARN_CFLAGS can be used.
As reported in https://bugs.freedesktop.org/show_bug.cgi?id=19283, the
fallback freetype version compare is broken inside the configure script as
the $1-$3 arguments are interpreted as the script is constructed. To avoid
making that awk comparison any more complicated, we import a version compare
from the autoconf archives - such that we have a reusable macro for the
furture.
Add a CairoScript interpreter library and use it to replay the test output
for the CairoScript backend. The library is also used by the currently
standalone Sphinx debugger [git://anongit.freedesktop.org/~ickle/sphinx].
The syntax/operator semantics are not yet finalized, but are expected to
mature before the next stable release.
A new meta-surface backend for serialising drawing operations to a
CairoScript file. The principal use (as currently envisaged) is to provide
a round-trip testing mechanism for CairoScript - i.e. we can generate
script files for every test in the suite and check that we can replay them
with perfect fidelity. (Obviously this does not provide complete coverage
of CairoScript's syntax, but should give reasonable coverage over the
operators.)
This tool can be used to trace all the cairo function calls made by an
applications. This is useful for either extracting a test case triggering
a bug from an application, or simply to get a general idea of how an
application is using cairo.
After make install, cairo-trace program arguments, will print out all the
cairo calls to the terminal and also capture theme in ./program.$pid.trace
The format of the output is CairoScript, watch this space for more
cairo-script tools!
Avoid calling libtool to link every single test case, by building just one
binary from all the sources.
This binary is then given the task of choosing tests to run (based on user
selection and individual test requirement), forking each test into its own
process and accumulating the results.
Dolt is a hack to speed up libtool-based build systems:
http://dolt.freedesktop.org/
It's completely transparent to the user. Brings make time
of cairo from 70s down to 20s. Yay!
Generate a cairo-perf-diff graph for a series of commits in order to be
able to identify significant commits. Still very crude, but minimally
functional.
Since CAN_TEST_PS_SURFACE does not currently require spectre, we were
attempting to compile in spectre support for any2ppm even on systems
without libspectre installed. Fix that by adding a separate flag for
CAIRO_HAS_SPECTRE.
These are the versions available on RHEL5 (two years old now), and
we know cairo works with them. There's evidence that our build system
does not work with older automake, and we've been requiring autoconf 2.58
but no one ever tested 2.58 with the new build system. It's very likely
that 2.58 doesn't work and needs some macro backporting. In any case,
no one reported that they have 2.58 when I asked on the list.
After going to the effort of detecting zlib for cairo-deflate-stream.c, it
rather defects the purpose of the exercise (and the mingw32 build) if we
forget to add the library to LIBS.
