Images with EXTEND_PAD are painted into a new image the size of the
operation extents. The new image is then embedded in the PS file with
the pattern matrix adjusted to ensure the image origin is in the
correct location.
Images with EXTEND_PAD are painted into a new image the size of the
operation extents. The new image is then embedded in the PDF file with
the pattern matrix adjusted to ensure the image origin is in the
correct location.
The extents will be used by EXTEND_PAD patterns as well as any other
pattern that can benefit from knowing the extents of the operation it
will be used with.
To be able to provide the extents of each operation to the backend
during the render phase the meta-surface needs to store the extents
computed by the analysis surface during the analysis phase.
The extents argument is either a pointer to the extents of the operation
stored in the meta-surface or NULL. During analysis the analysis surface
writes the extents to the meta-surface. During the render phase the extents
is made available to paginated surface backends.
Add a "cairo_rectangle_int_t *extents" argument to to the following
backend functions:
paint
mask,
stroke
fill
show_glyphs
show_text_glyphs
This will be used to pass the extents of each operation computed by
the analysis surface to the backend. This is required for implementing
EXTEND_PAD.
First of a simple substitution for -?-, as they are very confusing in
context with other minus signs floating around.
Carl has promised to go over these docs with me at the HackFest in order
to improve them (and verify them).
Include a COPYING inside perf/, test/, util/ to clarify the licensing
conditions beneath the respective directories. This is because cairo
itself (libcairo.so) is LGPL-2.1/MPL-1.1 but that only relates to src/.
The auxiliary source files are under a mix of free licenses and we wish to
be clear just what license applies to each file.
In particular, cairo-trace needs to include the GPL terms and conditions.
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!
We frequently use '-' within the test name or format name and so we
encounter confusion as '-' is also used as the field separator. At times
this has caused a new test to break an old test because the new test would
match one of the old test's target specific reference images. So switch
everything over to use '.' between fields (test name, target, format,
subtest, etc.).
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.
test/text-glyph-range was crashing since we requested the meta_surface but
the glyph wrongly believed it already had the meta_surface but was
checking for a path instead.
If the filter mode is anything other than DEFAILT, FAST or NEAREST set the
Interpolate flag in the image dictionary so that a smoothing filter is
applied when rasterising the vector file.
As we have no control over the implementation of the Interpolate filter
(the PS/PDF specifications leave it undefined) we need to capture the
output of poppler/GS and update our reference images. (For a couple of
tests, the filtering is irrelevant so for those we set the filter to
NEAREST.)
Note that GhostScript's Interpolate filter does not work on rotated images
(and a variety of other transformations) so several of the PS reference
images have use nearest-neighbour sampling instead of a bilinear filter.
Fallback images should (in theory) be emitted at native resolution, so
disable filtering to avoid introducing potential artifacts into cairo's
ideal output.
Behdad wants to include the feature with 1.10, so we enable it as early as
possible in 1.9 dev cycle to generate as much feedback as possible.
The first change is to use "<cairo>" as being a name unlikely to clash
with any real font names.
This reverts commits:
a824d284be,
2922336855,
e0046aaf41,
f534bd549e.
Instead of maintaining an index and comparing it to the count, just mark
the last startstop event with NULL and stop dequeuing events upon seeing
that sentinel value. (Removes an unreadable line, and cachegrind hints
that it may be a tiny bit faster.)
First check if we can reject the intersection without having to perform
the full divides, based on analysing:
t * (ady*bdx - bdy*adx) = bdy * (ax - bx) - bdx * (ay - by)
s * (ady*bdx - bdy*adx) = ady * (ax - bx) - adx * (ay - by)
and excluding the result if by inspection we know that
(s, t) <= 0 || (s, t) => 1.
Doing so virtually eliminates all division and speeds up the strokes (when
performing self-intersection elimination using the tessellator) perf cases
by about 5%.
Use our prior knowledge of the inputs and trivial conditions to simplify
the edge equations and in many common conditions, such as vertical edges
and common points, reduce the operations down to a just returning the
non-degenerate 32 bit value. This adds an overhead of a few conditionals,
but on the fast paths we actually generate fewer branches and many fewer
arithmetic operations such that it improves performance of the fill
performance tests by around 10%.
The matrix is quite often just a simple scale and translate (or even
identity!). For this class of matrix, we can skip the full adjoint
rearrangement and determinant calculation and just compute the inverse
directly.
libXrender amalgamates sequences of XRenderFillRectangle() into a single
XRenderFillRectangles request (when permissible). Since it is common for a
cairo application to draw rectangles individually in order to exploit fast
paths within cairo [rectilinear fills], it is a reasonably common pattern.
No need to copy font options if the similar surface is from the same
backend and no special options have been applied by the user. Doing so
breaks lazy initialisation of backend specific options.
Constructing the font options cause the initialisation of Xlc and invoke
several round-trips to the X server, significantly delaying the creation
of the first surface. By deferring that operation until the first use of
fonts then we avoid that overhead for very simple applications (like the
test suite) and should improve start-up latency for larger application.
Exploit the auxiliary offset vector in the attributes to reduce
likelihood of range overflow in the translation components when converting
the pattern matrix to fixed-point pixman_matrix_t.
An example of this is bug 9148
Bug 9148 - invalid rendering when painting large scaled-down surfaces
(https://bugs.freedesktop.org/show_bug.cgi?id=9148)
but the issue is perhaps even more likely with high resolution fallback
images.
