Due to caching, destruction of X11 resources may occur outside of a
usable X11 context. To avoid this, we defer the destruction onto a work
queue which will be run the next time we try to use the X11 connection
on behalf of the user (at which point we must have a usable X11 context!)
or we are closing the Display.
Due to the nature of the reference counting, an X resource may be
destroyed later than anticipated and possibly from a different thread
than the original context. This becomes an issue for applications that
carefully manage their single X connection from a single thread and do
not use locking and are then suprised when cairo triggers X traffic when
performing work for a different part of the application in another thread.
Previously, we stored the per-display attributes inside a special
screen=NULL _cairo_xlib_screen_info_t. Now we keep track of known X
displays and store the screen information beneath the display structure
alongside the per-display hooks.
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.
