All mutex declarations have been moved to cairo-mutex-list.h.
This should avoid breaking of less frequently tested backends,
when mutexes are introduced or when existing mutexes are renamed.
Instead of initializing mutexes on library startup, mutexes are
lazily initialized within the few entry points of now by calling
CAIRO_MUTEX_INITIALIZE(). Currently only the OS/2 backend takes
care about releasing global mutexes. Therefore there is no counter
part of that macro for finalizing all global mutexes yet - but
as cairo-backend-os2.c shows such a function would be quite
easy to implement.
This reverts the following commits:
2715f2098167e3b3c53b
See this thread for an analysis of the problems it caused:
http://lists.freedesktop.org/archives/cairo/2007-February/009825.html
In short, a single cache for all backends doesn't work, as one thread
using any backend can cause an unused xlib pattern to be evicted from
the cache, and trigger an xlib call while the display is being used
from another thread. Xlib is not prepared for this.
This was needed for SVG backend because it does not implement clone_similar.
However, I'm worried about possible infinite recursion here. Not sure what
to do.
We do this through a hack, that is, we make
_cairo_pattern_acquire_surface to return a surface that has four
copies of the original surface painted such that this image can
be simply repeated to get the effect of reflecting the original
surface.
This fixes the formerly XFAIL test extend-reflect.
Previous commit broke cairo_surface_finish, since it was checking for
ref_count == CAIRO_REF_COUNT_INVALID and bailing. But, that condition
was reached from destroy, so finish was bailing out early.
user_data setters/getters were added to public refcounted objects
that were missing them (cairo_t, pattern, scaled_font). Also,
a refcount getter (cairo_*_get_reference_count) was added to all
public refcounted objects.
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.
Only surfaces that are "compatible" are used. The definition of compatible
is backend specific. For the xlib backend, it means that the two surfaces
are allocated on the same display. Implementations for compatibility are
provided for all backends that it makes sense.
Rotation and other transformations would cause extents to be
computed which were outside the bounds of the surface to be
cloned, (and for non repeating patterns). Now we simply
restrict the computed extents to the surface extents.
This fixes the xlib failure of the recent rotate-image-surface-paint
test, (the apparently distinct ps failure remains).
It turns out that all of the callers want a box anyway, so this
simplfies the code in addition to being more honest to the name.
(For those new to the convention, a "box" is an (x1,y2),(x2,y2)
pair while a "rectangle" is an (x,y),(width,height) pair.)
This broke with the clone_similar optimization in
8d7a02ed58 The optimization added an
interest rectangle to clone_similar, but with a repeating source
pattern, the interest rectangle might not intersect the extents of the
surface at all.
The test suite caught this with the trap-clip case.
The fix here is to clone the entire surface if the pattern has an
extend mode of REPEAT.
This broke with the clone_similar optimization in
8d7a02ed58
The optimization added an interest rectangle to clone_similar,
but the acquire_surface path was neglecting to transform its
rectangle by the pattern matrix.
The test suite did catch this, but apparently we were too
distracted by the performance improvements to notice. Only
backends other than image that implemented clone_similar
would be affected by the bug, (which meant I only saw xlib
failures in my testing).
This fixes bug #8711
This fixes a huge performance bug (entire image was being pushed to X
server in order to copy a tiny piece of it). I see up to 50x improvement
from subimage_copy (which was designed to expose this problem) but also
a 5x improvement in some text performance cases.
xlib-rgba subimage_copy-512 3.93 2.46% -> 0.07 2.71%: 52.91x faster
███████████████████████████████████████████████████▉
xlib-rgb subimage_copy-512 4.03 1.97% -> 0.09 2.61%: 44.74x faster
███████████████████████████████████████████▊
xlib-rgba subimage_copy-256 1.02 2.25% -> 0.07 0.56%: 14.42x faster
█████████████▍
xlib-rgba text_image_rgb_over-256 63.21 1.53% -> 11.87 2.17%: 5.33x faster
████▍
xlib-rgba text_image_rgba_over-256 62.31 0.72% -> 11.87 2.82%: 5.25x faster
████▎
xlib-rgba text_image_rgba_source-256 67.97 0.85% -> 16.48 2.23%: 4.13x faster
███▏
xlib-rgba text_image_rgb_source-256 68.82 0.55% -> 16.93 2.10%: 4.07x faster
███▏
xlib-rgba subimage_copy-128 0.19 1.72% -> 0.06 0.85%: 3.10x faster
██▏
In particular, many possible error values on a surface provided
to cairo_pattern_create_for_surface were previously being swallowed
and a nil pattern was returned that erroneously reported
CAIRO_STATUS_NO_MEMORY.
Adds API functions for inspecting the current dash state, as well as
the contents of pattern objects:
cairo_get_dash
cairo_get_dash_count
cairo_pattern_get_rgba
cairo_pattern_get_surface
cairo_pattern_get_color_stop_rgba
cairo_pattern_get_color_stop_count
cairo_pattern_get_linear_points
cairo_pattern_get_radial_circles
A recent renaming from CAIRO_MAXSHORT also changed the range of some
values from INT16_MAX to UINT16_MAX. The test suite shows one case
where this introduces a bug, (push/pop_group with SVG and RGB24
surfaces).
I haven't tracked the bug down, (presumably there's overflow of the
unsigned value at some point), but I'm now reverting this to avoid
triggering the bug.
This rectangle has regular integer values, not fixed-point values.
So the old name was horribly wrong and misleading, (and yes I think
it was even I that had suggested it).
This patch was produced with the following (GNU) sed script:
sed -i -r -e 's/[ \t]+$//'
run on all *.[ch] files within cairo.
Note that the above script would have also created all the changes
from the previous commits to remove trailing whitespace.
This patch was produced with the following (GNU) sed script:
sed -i -r -e '/^[ \t]*\/?\*/ s/[ \t]+$//'
run on all *.[ch] files within cairo, (though I manually excluded
src/cairo-atsui-font.c which has a code line that appears as a comment
to this script).
