During the pixman_op, a complicated dance is performed to handle
enlarging the rectangle array to accommodate the op. One consequence
of this is to, under certain circumstances, replace the current
rectangle array with emptyData and track the old array with oldData.
Hence if we fail to realloc the enlarged array we need to free oldData.
_cairo_pattern_acquire_surfaces() may substitute an image surface for
either the source or the mask should the backend not support creation
of similar scratch surfaces or an error occurs during creation. For
composition we require xlib surfaces and so we must trigger the
fallback path if this happens.
as now the mutex layer will define a generic CAIRO_MUTEX_FINALIZE()
whenever the implementation defines CAIRO_MUTEX_FINI(). In the
case of pthread however we don't need finalization as we don't
have any place to call it, and pthread_mutex_destroy() doesn't
do much anyway.
Previously cairo-mutex.c was abusing cairo-mutex-private.h by
defining CAIRO_MUTEX_DECLARE before including it, and
cairo-mutex-private.h was simply not overriding any available
CAIRO_MUTEX_DECLARE. This is not the way it should be.
cairo-mutex.c should instead define CAIRO_MUTEX_DECLARE and
include cairo-mutex-list-private.h for itself.
If we create the Pixmap whilst constructing a similar xlib surface, then
it our responsibility to free the Pixmap should we fail to allocate the
surface.
This fixes the problem reported by Dave Yeo that boilerplate wasn't building:
In file included from ../src/cairo-scaled-font-private.h:44,
from cairo-boilerplate.c:65:
../src/cairo-mutex-private.h:183: error: syntax error before "extern"
../src/cairo-mutex-private.h:184: error: syntax error before "void"
../src/cairo-mutex-private.h:185: error: syntax error before "void"
make[3]: *** [cairo-boilerplate.lo] Error 1
The WINVER macros need to be defined before including <windows.h>.
As a result of some recent include file rearranging, <windows.h>
was included indirectly before WINVER was defined.
Similar to cairo-test, we free any global memory used by cairo for its
caches through the debug interfaces. We do this so that valgrind does
not unnecessary warn about memory leaks for the cached data and any true
leak is then not lost in the noise.
It's quite simple to add a new _cairo_traps_limit call which installs
a box into the cairo_traps_t structure. Then at the time of
_cairo_traps_add we can discard any trapezoid that is wholly outside
the box and also clip any trapezoid that is partially outside the box.
We take advantage of this for both cairo_stroke and cairo_fill, (when
cairo is computing the trapezoids in cairo-surface-fallback.c). Note
that we explicitly do not do any clipping for cairo_stroke_extents,
cairo_fill_extents, cairo_in_stroke, or cairo_in_fill which are
defined to ignore clipping.
As seen by the long-lines perf case, this fix successfully works
around the bug in the X server where it creates overly large masks for
partially-outside-the-destination-surface trapezoids:
xlib-rgba long-lines-uncropped-100 545.84 -> 5.83: 93.09x speedup
██████████████████████████████████████████████
xlib-rgb long-lines-uncropped-100 554.74 -> 8.10: 69.04x speedup
██████████████████████████████████
The following four tests are disabled:
gradient-alpha, linear-gradient, text-pattern, trap-clip
We don't use XFAIL as that would disable all backends, (but
we can still usefully use these tests on backends other than
PDF).
Some PDF viewers forget the CTM when drawing gradient patterns
with SMasks. This patch works around these bugs by using the default
identity matrix for the CTM. All paths are transformed from
cairo to pdf coordinates before writing to the pdf file.
Previously, if the change in the first test case was small enough
to be considered insignificant, then the header lines showing the
names of the old and new configurations would be omitted. This
commit fixes that bug.
And re-enable fbCompositeSrc_8888x8x8888mmx now that it should work.
This gives another little boost to the paint-with-alpha perf test:
image-rgba paint-with-alpha_image_rgba_over-512 11.76 -> 5.20: 1.85x speedup
▉
image-rgb paint-with-alpha_image_rgba_over-512 11.76 -> 5.26: 1.84x speedup
▉
Now, if you pass exactly two performance reports on the command line
you'll get the traditional report style again, (so the tool remains
backwards compatible). If you really want the new style with two
reports you can get it by adding /dev/null as a third argument.
This support is intended to compare the identical backends across multiple
reports from several different configurations, (of one sort or another).
The configuration names used in the report are taken from the filenames
of the report files, (which will format most nicely if 8 characters or
less).
The traditional two-input report mode, (showing one line perdiff with
all speedups before all slowdowns), is removed with this commit, but
is intended to return again shortly.
We terminate the iteration by adding a final report with a NULL
name. This will simplify future code that iterates over more than
two reports simultaneously.
An upcoming change will allow cairo-perf-diff-files to generate
a report based on more than two files. This prepares for that by
moving the minimum-change support from the 3rd positional argument
to a new --min-change option.
