After discussing the scaled font locking with Behdad, it transpired that it
is not sufficient for a font to be locked for the lifetime of a scaled glyph,
but that the scaled font's glyph cache must be frozen for the glyph'
lifetime. If the cache is not frozen, then there is a possibility that the
glyph may be evicted before the reference goes out of scope i.e. the glyph
becomes invalid whilst we are trying to use it.
Since the freezing of the cache is the stronger barrier, we remove the
locking/unlocking of the mutex from the backends and instead move the
mutex acquisition into the freeze/thaw routines. Then update the rule on
acquiring glyphs to enforce that the cache is frozen and review the usage
of freeze/thaw by all the backends to ensure that the cache is frozen for
the lifetime of the glyph.
Dolt is a hack to speed up libtool-based build systems:
http://dolt.freedesktop.org/
It's completely transparent to the user. Brings make time
of cairo from 70s down to 20s. Yay!
Bug 18140 identifies a case where we have an atomic increment, but not an
atomic exchange. We need both to implement atomic reference counting, so
add a second check to detect whether __sync_val_compare_and_swap
generates a non-atomic instruction.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=18140.
Mention in the API docs that you can pass a NULL filename to
cairo_(pdf|ps|svg)_surface_create in order to construct a queryable
surface without generating any temporary files. Similarly when passing a
NULL write_func to cairo_pdf_surface_create_for_stream et al.
The current version of DirectFB does not support any filters, so set
NEAREST on the source patterns so that we can fully optimize the pattern
inside core.
If we have non-integer translation on a source pattern then we need to use
STRECTHBLIT (the core takes care to optimize NEAREST patterns to integer
translations so that this will only be used when interpolation is
required).
Create an RGB or ARGB surface depending upon the content type of the test
target, with the result that the directfb rgb24 target no longer
unconditionally fails.
PS (ghostscript) interprets the degenerate end-caps quite differently, and
perhaps slightly more rationally... Add this to XFAIL, until we have a
definitive specification on how we should behave.
Generate a cairo-perf-diff graph for a series of commits in order to be
able to identify significant commits. Still very crude, but minimally
functional.
Allow the user to specify a NULL write_func for the output stream so that
a dummy surface can be created, for example, for querying target font
options or font extents.
Currently we do not perform any sanity checks at the user entry point and
will generate a mysterious SEGV during cairo_surface_finish() - which may
not immediately be obvious that it is due to a NULL write_func.
