Check for an allocation failure during _cairo_analysis_surface_create()
and propagate to caller - where we discover that the callers themselves
missed the status checks...
_cairo_surface_create_similar_solid() may return an image surface,
should the backend not support the required content or should it
encounter an error whilst creating the surface. In those circumstances
we choose not to cache the fallback surface.
Original work by Jorn Baayen <jorn@openedhand.com>,
2715f20981
We use a small cache of size 16 for surfaces created for solid patterns.
This mainly helps with the X backends where we don't have to create a
pattern for every operation, so we save a lot on X traffic. Xft uses a
similar cache, so cairo's text rendering traffic with the xlib backend
now completely matches that of Xft.
The cache uses an static index variable, which itself acts like a cache of
size 1, remembering the most recently used solid pattern. So repeated
lookups for the same pattern hit immediately. If that fails, the cache is
searched linearly, and if that fails too, a new surface is created and a
random member of the cache is evicted.
A cached surface can only be reused if it is similar to the destination.
In order to check for similar surfaces a new test is introduced for the
backends to determine that the cached surface is as would be returned by
a _create_similar() call for the destination and content.
As surfaces are in general complex encapsulation of graphics state we
only return unshared cached surfaces and reset them (to clear any error
conditions and graphics state). In practice this makes little difference
to the efficacy of the cache during various benchmarks. However, in order
to transparently share solid surfaces it would be possible to implement a
COW scheme.
Cache hit rates: (hit same index + hit in cache) / lookups
cairo-perf: (42346 + 28480) / 159600 = 44.38%
gtk-theme-torturer: (3023 + 3502) / 6528 = 99.95%
gtk-perf: (8270 + 3190) / 21504 = 53.29%
This translates into a reduction of about 25% of the XRENDER traffic during
cairo-perf.
By deferring the issuing of the X requests to set the clip mask we can
theoretically avoid some redundant requests, but primarily we remove
another path where X requests are emitted.
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.
