Prior to introduction of the buggy members to the surface, we obviously
cannot set them. However, the boilerplate code is meant to compile against
older revisions of the library so we need to check for the existence prior
to use.
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.
Handling clip as part of the surface state, as opposed to being part of
the operation state, is cumbersome and a hindrance to providing true proxy
surface support. For example, the clip must be copied from the surface
onto the fallback image, but this was forgotten causing undue hassle in
each backend. Another example is the contortion the meta surface
endures to ensure the clip is correctly recorded. By contrast passing the
clip along with the operation is quite simple and enables us to write
generic handlers for providing surface wrappers. (And in the future, we
should be able to write more esoteric wrappers, e.g. automatic 2x FSAA,
trivially.)
In brief, instead of the surface automatically applying the clip before
calling the backend, the backend can call into a generic helper to apply
clipping. For raster surfaces, clip regions are handled automatically as
part of the composite interface. For vector surfaces, a clip helper is
introduced to replay and callback into an intersect_clip_path() function
as necessary.
Whilst this is not primarily a performance related change (the change
should just move the computation of the clip from the moment it is applied
by the user to the moment it is required by the backend), it is important
to track any potential regression:
ppc:
Speedups
========
image-rgba evolution-20090607-0 1026085.22 0.18% -> 672972.07 0.77%: 1.52x speedup
▌
image-rgba evolution-20090618-0 680579.98 0.12% -> 573237.66 0.16%: 1.19x speedup
▎
image-rgba swfdec-fill-rate-4xaa-0 460296.92 0.36% -> 407464.63 0.42%: 1.13x speedup
▏
image-rgba swfdec-fill-rate-2xaa-0 128431.95 0.47% -> 115051.86 0.42%: 1.12x speedup
▏
Slowdowns
=========
image-rgba firefox-periodic-table-0 56837.61 0.78% -> 66055.17 3.20%: 1.09x slowdown
▏
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.
By moving the backend target definition out of the massive amlagamated
block in cairo-boilerplate.c and into each of the
cairo-boilerplate-backend.c, we make it much easier to add new targets as
the information need only be entered in a single file and not scattered
across three. However, updating the target interface means trawling across
all the files -- except given that I found it difficult maintaining the
single massive array I do not see this as an increase in the maintenance
burden.
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.
During cairo_boilerplate_get_image_surface_from_png() the original status
returned by cairo_image_surface_create_from_png() could have been masked
by inappropriate context construction when flattening or extracting.
Simply check after creating the surface from the png file, and return
immediately if in error.
Only use the RGB16_565 surface as a source during testing. We presume that
pixman is itself rigorously tested and the output is equivalent to the
image surface. Enabling this test surface would require too large of a
burden to maintain the reference images for the 16-bit backend.
Test case for:
Bug 22441 -- Unexpected shift with push_group and pop_group
https://bugs.freedesktop.org/show_bug.cgi?id=22441
This is a test that demonstrates the error in the pdf backend when using
groups on surfaces with non-integer sizes. In order to create such a
surface, we need to update the boilerplate to use doubles instead of
integers when specifying the surface size.
Create an xlib target that uses a separate display, specified by
CAIRO_REFERENCE_DISPLAY, that can be used as a reference implementation
for the normal display. So this can be used by cairo-trace-test to create
a reference surface that mimics exactly the true surface, but if it
targets an Xvfb display will be entirely rendered in software. If
CAIRO_REFERENCE_DISPLAY is not set, the reference surface degrades into an
xlib-fallback surface which is a close approximation (but still has
behavioural differences).
Specify another boilerplate target to use as the reference for this
target. We then use this in cairo-test-trace in preference to using the
image surface. Still not perfect, though the framework is improving.
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>
Using a null surface is a convenient method to measure the overhead of the
performance testing framework, so export it although as a test-surface so
that it will only be available in development builds and not pollute
distributed libraries.
Improve the 'Cannot find target ...' error message for an incorrect
CAIRO_TEST_TARGET by actually listing the targets that have been compiled
into the test suite.
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
Add a variation of test-fallback-surface that forces the use of a 16-bit
pixman format code instead of the standard 32-bit types. This creates an
image surface akin to the fallbacks used with low bit-depth xservers.
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.
Currently glyphs are cached independently in each font i.e. each font
maintains a cache of up to 256 glyphs, and there can be as many scaled fonts
in use as the application needs and references (we maintain a holdover
cache of 512 scaled fonts as well).
Alternatively, as in this patch, we can maintain a global pool of glyphs
split between all open fonts. This allows a heavily used individual font
to cache more glyphs than we could allow if we used per-font glyph caches,
but at the same time maintains fairness across all fonts (by using random
replacement) and provides a cap on the maximum number of global glyphs.
The glyphs are allocated in pages, which are cached in the global pool.
Using pages means we can exploit spatial locality within the font
(nearby indices are typically used in clusters) to reduce frequency of small
allocations and allow the scaled font to reserve a single MRU page of
glyphs. This caching dramatically reduces the cairo overhead during the
cairo-perf benchmarks, and drastically reduces the number of allocations
made by the application (for example browsing multi-lingual site with
firefox).
If we cannot test the xlib backend simply because there is no Display,
just report UNTESTED and do not clutter the output with superfluous
warnings [see the output from the buildbots for an example]. However,
keep the warnings around so that a developer can re-enable them
and so simply move them to a new "lower priority" macro.
