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>
As handling joins/caps between line segments shorter than
half_line_width is tricky.
Rather than also fixing the bug in traps, remove that code. The plan is
to avoiding hitting the traps code, short-circuiting several steps along
the fast rectangular paths.
Fixes line-width-overlap.
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>
Step 1, fix the failings sighted recently by tracking clip-boxes as an
explicit property of the clipping and of composition.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order for custom context to automatically track when a pattern is
modify after being set on the context (and before it is used in an
operator), we need for there to be a callback when the pattern is
modified.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allow a backend to completely reimplement the Cairo API as it wants. The
goal is to pass operations to the native backends such as Quartz,
Direct2D, Qt, Skia, OpenVG with no overhead. And to permit complete
logging contexts, and whatever else the imagination holds. Perhaps to
experiment with double-paths?
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>
cairo-perf-trace uses cairo-hash.c, which calls _cairo_error.
Instead of redefining it in cairo-perf-trace.c it can be abstracted in
a separate source which is directly included in the build of
cairo-perf-trace.
This avoids visibility issues when compiling cairo-perf-trace with a
statically linked cairo library on architectures which do not support
hidden visibility (example: win32).
make on win32 complains that:
make[1]: Entering directory `/home/ranma42/Code/fdo/cairo/src'
../src/Makefile.sources:220: *** missing separator. Stop.
Makefile.sources should not contain if's, which are aoutomake-only
conditionals. The correct way to conditionally include files is to
enable/disable them using C preprocessor macros.
PS and PDF have native support for mesh patterns, but they have encode
mesh points and colors in an appropriate binary stream.
cairo_pdf_shading_* functions implement the encoding, which is the
same for PDF and PS.
Some GL functions can be called using different names depending on the
GL version and available extensions (ARB, EXT). The dispatch table
abstracts these differences and provides a uniform API for dealing with
these functions.
The latin subsets feature requires these names. As
cairo-type1-subsets.c depends on FreeType, move these names out to a
separate file to allow compilation without FT.
The cairo-freelist-private.h header has a number of static inline
functions which call hidden functions in libcairo. This poses
a problem on Solaris where the native compiler compiles inline
functions whether they are used or not, thereby adding the
link time requirements on hidden functions from whatever code
that includes cairo-freelist-private.h. Unfortunately the
boilerplate code includes cairo-private headers and indirectly
the freelist header, so linking the boilerplate helper library
fails on Solaris.
This patch separates the structure definitions from the function
prototypes and static inlines in cairo-freelist-private.h by moving
the datatypes to a new cairo-freelist-type-private.h.
A stray backslash bwetween two assignment lines apparently
invokes a GNU make extension for conditional assignments.
This patch fixes the build when using the native Solaris make.
Currently wether internal glew is built is dependant on wether the
tarball in use was built with internal glew or not. And that's not how
it should be.
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
Use cairo_drm_xr_sources/headers for the drm_xr stuff. This makes it
work correctly in gtk-doc instead of conditionally adding it to
cairo_drm_sources/headers.
Commit 8d67186cb2 caches whether the device
transform is identity on context creation. However, the api is quite lax
and allows the user to modify the device transform *after* he has
started to use the surface in a context, as apparently WebKit does.
Since this is not the only instance where we may need to invalidate
caches if the user modifies state, introduce a simple mechanism for
hooking into notifications of property changes.
Fixes test/clip-device-offset.
This allows designing a cleaner interface for cairo_composite_t as there
will not be static functions that get called outside of the "published"
interfaces.
Trying to build xcb on a system without SHM wrapped by xcb. The right
answer would be to build libxcb-shm. The quick answer is to compile out
shm support.
Still an experimental backend, it's now a little too late to stabilise
for 1.10, but this should represent a major step forward in its feature
set and an attempt to catch up with all the bug fixes that have been
performed on xlib. Notably not tested yet (and expected to be broken)
are mixed-endian connections and low bitdepth servers (the dithering
support has not been copied over for instance). However, it seems robust
enough for daily use...
Of particular note in this update is that the xcb surface is now capable
of subverting the xlib surface through the ./configure --enable-xlib-xcb
option. This replaces the xlib surface with a proxy that forwards all
operations to an equivalent xcb surface whilst preserving the cairo-xlib
API that is required for compatibility with the existing applications,
for instance GTK+ and Mozilla. Also you can experiment with enabling a
DRM bypass, though you need to be extremely foolhardy to do so.
As proof-of-principle add the nearly working demonstrations of using DRM
to render directly with the GPU bypassing both RENDER and GL for
performance whilst preserving high quality rendering.
The basis behind developing these chip specific backends is that this is
the idealised interface that we desire for this chips, and so a target
for cairo-gl as we continue to develop both it and our GL stack.
Note that this backends do not yet fully pass the test suite, so only
use if you are brave and willing to help develop them further.
This is a highly specialised scan converter for the relatively common
case of where the input geometry is known to be a series of rectangles.
Generally not device aligned (or else we would most likely have chosen
an even higher performance path that does not require a coverage mask),
this optimised converter can simply compute the analytical coverage by
utilising a special case Bentley-Ottmann intersection finder.
This variant uses the Bentley-Ottmann algorithm to only maintain the
active edge list upon edge events and so can efficiently skip areas
where no change occurs. This means that it can be much quicker than the
Tor algorithm (which is still used to compute the coverages from the
active edges) for geometries consisting of long straight lines with few
intersections. However due to the computational overhead of the
Bentley-Ottmann event processing, for dense curvy paths, simply updating
the active edge list in sync with computing the coverages is a win. Due
to advantageous adaptive step size, the scan converter can be run at a
much higher subsampling with little extra overhead compared with Tor,
currently it uses a 256x256 subsampling grid to avoid any impedance
mismatch with path precision.
Given the current status of implementations, this scan converter [botor]
is likely to be advantage where detecting large regions of unchanged
span data will result in improved performance, for instance the drm
backends which convert the scan data into rectangles.
Currently we use cairo_traps_t to also pass around arrays of boxes. This
is woefully inefficient in terms of storage, but also means that we
repeatedly have to verify that the traps are a set of boxes. By
explicitly passing around a cairo_boxes_t we avoid the semantic loss.
This will be heavily used in pending commits.
This is a more useful definition that is able to individually track the
rectangles that compose the composite operation. This will be used by
the specialist compositors as a means to perform the common extents
determination for an operation.
The device is a generic method for accessing the underlying interface
with the native graphics subsystem, typically the X connection or
perhaps the GL context. By exposing a cairo_device_t on a surface and
its various methods we enable finer control over interoperability with
external interactions of the device by applications. The use case in
mind is, for example, a multi-threaded gstreamer which needs to serialise
its own direct access to the device along with Cairo's across many
threads.
Secondly, the cairo_device_t is a unifying API for the mismash of
backend specific methods for controlling creation of surfaces with
explicit devices and a convenient hook for debugging and introspection.
The principal components of the API are the memory management of:
cairo_device_reference(),
cairo_device_finish() and
cairo_device_destroy();
along with a pair of routines for serialising interaction:
cairo_device_acquire() and
cairo_device_release()
and a method to flush any outstanding accesses:
cairo_device_flush().
The device for a particular surface may be retrieved using:
cairo_surface_get_device().
The device returned is owned by the surface.
