The code in that cache is becoming uglier and uglier. But at least it
works correctly again. Time for a rewrite.
(Also move the destroy after unlocking)
Behdad Esfahbod complained that commit
8457374c9c overwhelmed the function with
added complexity and arbitrary limited a backend to one-quarter of the
cache. The elegant solution, he outlined, was to look at the surface that
would be evicted and if possible repaint it, instead of creating a
replacement. This not only simplifies the code, reduces the number of
checks performed to find a match (or victim) and allows the cache to be
naturally shared between the various backends.
cairo_surface_destroy and _cairo_scaled_font_fini will call destroy closures
which may call functions that attempt to acquire the mutex resulting in a
deadlock. We fix this by releasing the lock for the call to
cairo_surface_destroy or _cairo_scaled_font_fini.
This reverts commit ddcd6781a2.
This was an experimental commit that was intended to be on a side
branch but accidentally got committed and pushed to master. Sorry
for the noise.
This is an initial attempt at addressing the recently noticed
fallback-resolution bug. It isn't working correctly yet.
I'm just committing so that behdad can see what I'm up to.
With things like meta-surface, the assumption that coordinates are always
non-negative make no sense. Extend the "infinite" extents accordingly.
Also remove stale comment. extents->width/height are unsigned these days and
cover the full range.
The current solid surface cache returns an existing similar surface only
if it is an exact match for the desired colour. This gives a high hit
rate for the original goal of drawing text, but fails when using a lot
of colours - for example drawing a pie-chart, the mosaic perf case, or
browsing the web. So instead of creating a new surface from scratch we
can repaint an existing one, providing that we have sufficient surfaces
already cached, i.e. if we are going to evict a surface, we may as well
just repaint it.
This reverts commit 731e121c80.
This commit introduced various problems, (some likely noticeable
in the test suite, and others perhaps not). For some details, see
the latest comments in the original bug report leading to the
fix now being reverted:
http://bugs.freedesktop.org/show_bug.cgi?id=15349
This fixes the filter-bilinear-extents test case and the
related bug entry:
bad clipping with EXTEND_NONE
http://bugs.freedesktop.org/show_bug.cgi?id=15349
Though there are still differences in the PDF and PostScript
backends, (primarily because we can't capture cairo's filter
modes in those file formats).
Previously we were using the cairo_fixed_t type which meant we've
historically only been using 16 bits of precision for these offsets,
and recently only 8 bits. Meanwhile, all manipulatons of offsets
have been in floating-point anyway, so we might as well store them
that way.
This change also prevents a rendering regression introduced with the
24.8->16.16 change betwen snapshots 1.5.10 and 1.5.12 .
This change affected gradient-rendering details for the clip-operator
and operator-source tests, so the corresponding reference images are
updated here.
On the default case for an unknown pattern type, add an assert that the
code is never reached, and just in case upgrade the error to a fatal
PATTERN_TYPE_MISMATCH.
test/pattern-get-type exposes a bug whereby we try to acquire the
_cairo_pattern_solid_pattern_cache_lock before initializing the
mutexes. To fix this move the CAIRO_MUTEX_INITIALIZE() from the
depths of _cairo_pattern_init() and perform it at the public entry
points.
Every time we assign or return a hard-coded error status wrap that value
with a call to _cairo_error(). So the idiom becomes:
status = _cairo_error (CAIRO_STATUS_NO_MEMORY);
or
return _cairo_error (CAIRO_STATUS_INVALID_DASH);
This ensures that a breakpoint placed on _cairo_error() will trigger
immediately cairo detects the error.
Since the objects can be shared and may be in use simultaneously across
multiple threads, setting the status needs to be atomic. We use a
locked compare and exchange in order to avoid overwriting an existing
error - that is we use an atomic operation that only sets the new status
value if the current value is CAIRO_STATUS_SUCCESS.
Introduce an opaque cairo_reference_count_t and define operations on it
in terms of atomic ops. Update all users of reference counters to use
the new opaque type.
Introduce cairo_gradient_stop_t, and remove pixman dependency
for core pattern types. Perform conversion from cairo types
to pixman types as necessary in fallback code.
This patch introduces three macros: _cairo_malloc_ab,
_cairo_malloc_abc, _cairo_malloc_ab_plus_c and replaces various calls
to malloc(a*b), malloc(a*b*c), and malloc(a*b+c) with them. The macros
return NULL if int overflow would occur during the allocation. See
CODING_STYLE for more information.
