Ultimately, we want all of our paths to use shaders when they are
exposed -- it brings us closer to GL 3.0 compatibility and it should
reduce the work that GL drivers have to do per operation to compute
the required hardware state.
This appears to be the simplest mechanism to build libglew at the moment -
should a system copy be unavailable. Fortunately libglew is now distributed
under a permissive licence.
If you want to pass 'make -C src check' you have to use the system copy,
or spend quite a bit of time cairo-fying libglew.
Originally written by Vladimir Vukicevic to investigate using Skia for
Mozilla, it provides a nice integration with a rather interesting code
base. By hooking Skia underneath Cairo it allows us to directly compare
code paths... which is interesting.
[updated by Chris Wilson]
A very simple surface that produces a hierarchical DAG in a simple XML
format. It is intended to be used whilst debugging, for example with the
automatic regression finding tools of cairo-sphinx, and with test suites
that just want to verify that their code made a particular Cairo call.
Add a new surface type that multiplies it input onto several output
surfaces. The only limitation is that it requires a master surface that is
used whenever we need to query surface options, such as font options and
extents.
Add an even simpler sweep-line tessellator for rectangular trapezoids (as
produced by the rectilinear stoker and box filler).
This is so simple it even outperforms pixman's region validation code for the
purposes of path-to-region conversion.
For the frequent cases where we know in advance that we are dealing with a
rectilinear path, but can not use the simple region code, implement a
variant of the Bentley-Ottmann tessellator. The advantages here are that
edge comparison is very simple (we only have vertical edges) and there are
no intersection, though possible overlaps. The idea is the same, maintain
a y-x sorted queue of start/stop events that demarcate traps and sweep
through the active edges at each event, looking for completed traps.
The motivation for this was noticing a performance regression in
box-fill-outline with the self-intersection work:
1.9.2 to HEAD^: 3.66x slowdown
HEAD^ to HEAD: 5.38x speedup
1.9.2 to HEAD: 1.57x speedup
The cause of which was choosing to use spans instead of the region handling
code, as the complex polygon was no longer being tessellated.
In order to efficient store small images, we need to pack them into a
large texture. The rtree handles allocation of small rectangles out of a
much larger whole. As well as tracking free rectangles, it can also be
used to note which parts of the texture are 'pinned' -- that is have
operations currently pending and so can not be modified until that batch
of operations have been flushed. When the rtree is full, i.e. there is no
single free rectangle to accommodate the allocation request, it will
randomly evict an unpinned block large enough to fit the request. The
block may comprise just a single glyph, or a subtree of many glyphs. This
may not be the best strategy, but it is an effective start.
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.
Remove some redundant defining of surfaces and contexts and of setting
defaults. In order to reduce the number of defines, we need to operate on
the operand stack more frequently - though in practice those operations
are quite rare.
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.
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.
Imports a new polygon scan converter implementation from the
repository at
http://cgit.freedesktop.org/~joonas/glitter-paths/
Glitter paths is a stand alone polygon rasteriser derived from David
Turner's reimplementation of Tor Anderssons's 15x17 supersampling
rasteriser from the Apparition graphics library. The main new feature
in this implementation is cheaply choosing per-scan line between doing
fully analytical coverage computation for an entire row at a time
vs. using a supersampling approach.
A cairo_span_renderer_t implementation can be provided by a surface if
it wants to render paths as horizontal spans of the alpha component of
a mask. Its job is to composite a source pattern to the destination
surface when given spans of alpha coverage for a row while taking care
of backend specific clipping.
A cairo_scan_converter_t takes edges of a flattened path and generates
spans for a span renderer to render.
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.)
Benjamin Otte reports that in one particular benchmark cairo_in_fill() is
a hotspot in the profile. Currently we tessellate the entire path and then
search for a containing trapezoid. This is very expensive compared to the
simple method of counting the number of edge crossing between the point of
interest and x=-∞. For example, this speeds tessellate-256 up by almost 3
orders of magnitude.
The font data and rendering is adapted from Keith Packard's Twin
window system. The hinting stuff is not ported yet, but hey, it renders!
The implementation uses user fonts, and the user font backend is modified
to use this font face (which we call "twin" font face internally) when
a toy font is needed.
The font face layer is then modified to use this font if:
- The toy font face "cairo" is asked for, or
- No native font backend is available, or
- The preferred native font backend fails to return a font with
STATUS_UNSUPPORTED. No font backend does this right now but
the idea is to change FreeType to return it if no fonts found
on the system.
We also allow building with no font backends now!
The new doc/tutorial/src/twin.c file tests the twin face at various
sizes.
This is where DLL initialization/finalization should be done for example.
Moved the one for win32. For OS/2 just left a comment as the code needs
more work.
This change simplifies building shared and static libraries in the win32
makefiles.
