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).
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.
Principally to support creating a dummy vector surface (i.e.
cairo_ps_surface_create (NULL, 1, 1)) that can be used to determine font
extents (or target font options) before opening an output file, but also
because we currently fail to do any sanity checking at the entry point.
Simplify the error handling by only relinquishing the global
scaled_font_map mutex if we successfully insert the placeholder font. The
result is that on the error path, there are no changes to global state and
thus we can entirely skip the user-font initialisation and
re-registration.
If the surface is in error, then we cannot assume anything about the
validity of its contents other than the error status (and reference
count). This is for the cases were the surface is replaced by a nil
surface, and in future where the error surface may be replaced by a tiny
error object.
During map_glyph() we are passed a locked scaled_font for which we are
asked to add a glyph from that font into the active subsets for the
surface. This means that we eventually call scaled_glyph_lookup() to load
the glyph. But first, we attempt to find an existing an existing sub_font
for glyph, creating a new sub_font as necessary (possibly using an
entirely different unhinted scaled font). So before accessing the glyph
cache we need to make sure that we are holding the appropriate mutexes.
Avoid masking fatal errors by enforcing any error to be returned via an
error surface, so that the NULL return only means UNSUPPORTED. A few
backends called their create_similar() directly, without correctly checking
for a potential NULL (for example, the directfb backend was a timebomb,
since it used NULL to indicate out-of-memory).
lockdep is a valgrind skin which performs pthread locking correctness
validation. In particular it allows one to write assert(HOLDS_LOCK(mutex))
which both documents the preconditions for a function and enforces them
when the program is run under lockdep.
As an aide to lockdep (as it works by intercepting the pthread functions),
all the mutexes should be initialised and destroyed using
pthread_mutex_init() and pthread_mutex_destroy() rather than using static
initializers and no-ops.
Currently we only have an example of how to call FT_Done after the last
reference to the FT cairo_font_face_t has been dropped, but do not
actually explain why this needs to be done. So add a couple of sentences
to clarify the likely lifetime of the FT_Face once exposed to cairo.
Instead of fixing the check in d36b02dc66, just
remove it. Conditionally compilation will keep cairo-quartz-image-surface.c
from being compiled in when it is not configured to be. Suggested by Behdad.
glitz currently has no mechanism to release resources upon connection
closure (ala XCloseDisplay) and so will attempt invalid accesses when
evicting old surfaces from the solid pattern cache.
POSIX allows for any of its functions to be implemented as a macro,
inflicting damage upon innocent function pointers that happen to share
the same name.
face->stream->read() is one such example.
As it's outside of our control (being a FT_Face) we cannot simply rename
the data member, so we need to explicitly dereference it as a function
pointer in order to disambiguate it for the compiler.
Bug 9102 cairo doesn't support 24 bits per pixel mode on X11
(https://bugs.freedesktop.org/show_bug.cgi?id=9102)
is a reminder that that we need to support many obscure XImage formats.
With Carl's and Behdad's work to support psuedocolor we have a mechanism
in place to handle any format that is not natively handled by pixman. The
only piece we were missing was extending the swapper to handle all-known
formats and putting in defensive checks that pixels were correctly aligned
in accordance with pixman's requirements.
Emmanuel Pacaud did some research into adding DOCTYPE after we had a
complaint that our SVG output failed to be validated by batik. The
conclusion he came to was that the validation of SVG was incomplete and
misleading, i.e. our output might generate false negatives leading to more
confusion.
func_regexp was incorrectly complaining that cairo_pure was a function without
parenthesis. The simplest solution appeared to be allow quoting of
'cairo_pure'.
As is so often the case, reading the commit log gives you fresh insight in
the problem - often called confessional debugging...
We can simplify the problem by ignoring attr->[xy]_offset, for the time
being, and focus on computing the correct matrix. This is comparatively
simple as all we need to do is perform the appropriate rounding on the
translation vector.
