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.
A complication I realised after pushing 3eb4bc3 was handling larger
sampled areas. Extending the test case revealed that the optimization
was broken for anything but the identity transform (after removing the
translation). Correctness first, leaving the "pixel-exact" solution for
interested reader...
Carl suggested that cairo_pure and cairo_const are pretty opaque, even to
the developer who added them, so it is extremely important that they have
a good description so that they are used correctly and perhaps ported to
other compilers.
With the addition of cairo_show_text_glyphs() came a couple of functions
to query whether the target supported the extended attributes. However,
at Carl's request cairo_has_show_text_glyphs() was removed - but the
documentation was not updated to reflect that.
As identified in bug 15479,
Unpredictable performance of cairo-xlib with non-integer translations of a
source surface pattern
(https://bugs.freedesktop.org/show_bug.cgi?id=15479),
source surfaces with a fractional translation hit slow paths for some
drivers, causing seemingly random performance variations. As a work-around
Owen Taylor proposed that cairo could convert non-integer translations on
NEAREST sources patterns to their integer equivalents.
The messy detail involved here is replicating the rounding mode used by
pixman for the sample offset, but otherwise the conversion is fairly
trivial.
As proof-of-principle, compute a scale factor to avoid overflow when
converting a linear pattern to pixman_fixed_t. Fixes test/huge-pattern,
but the principle should be extended to handle more cases of overflow.
Bulia Byak reported a bug where cairo was crashing with a particular
font. The font had an incorrect entry in the cmap table that caused
cairo to read from outside of the buffer allocated for the cmap.
Bug 11734:
XRender crashes due to NULL pointer from Cairo on SGI O2
(https://bugs.freedesktop.org/show_bug.cgi?id=1173)
is an example of a case where we try to perform an XRender operation on a
surface with a format that was not supported by the XRender extension. By
marking the extension version as -1 on those surfaces, the current checks
for SURFACE_RENDER_HAS_* always correctly return false and prevent us try
to create a Picture with a NULL xrender_format.
Since cairo.h is a public header file, we need to be careful so that it
can be compiled by random compilers and even users specifying "-Werror
-Wundef" (mentioning no names, Company). So replace the bare (and legal)
#if _MSC_VER
with
#if defined (_MSC_VER)
just in case.
Missed updating win32 when implementing the new paginated API to query
support for the fine-grained fallbacks.
(Thanks to Adrian for spotting this oversight.)
The use of fine-grained fallbacks requires the native support of the
SOURCE operator applied to an image on the target surface. SVG 1.2
introduces the "comp-op:src" mode fulfilling this criteria - so we can
enable fine-grained fallbacks for 1.2+.
Update test/fine-grained-fallbacks to exercise this pathway in SVG 1.2 -
as SVG natively supported all the current operations within that test.
This reveals yet another librsvg bug in handling SVG 1.2.
Avoid passing a 32bit integer as a cairo_int64_t in case we do not have a
64bit native integral type. As a side-effect this means we can also use a
narrower multiply.
For the simple case where the pattern matrix only contains an integer
translation then care is taken to convert that to a identity source matrix
with the translation applied to the [xy]_offsets. 5b97ee6525 broke this
guarantee by applying the clone offsets to the source matrix. So when the
source matrix is identity we can simply adjust the [xy]_offsets and
preserve the identity matrix. (This idea can be extended further by
removing any integer translation from the source matrix and storing it in
the [xy]_offsets as a means to extend the limited precision in
pixman_matrix_t - encountered when downscaling large images offset onto
the target surface.)
A precondition for using the core XCopyArea protocol is that the source
attributes contain only integer translations. However, we failed to apply
any integer translations from the source matrix to the XCopyArea offsets.
This worked prior to 5b97ee6525 as
_cairo_pattern_acquire_surface_for_surface() was careful to only generate
an identity matrix if the pattern matrix only contained an integer
translation (and thus we would use XCopyArea in the xlib backend).
gtk-doc fails make check for array as it insists that even the simplest
functions must have a long description and cannot be entirely described by
their arguments and return value.
During insertion we must traverse the skiplist in order to find the
insertion point for the new element. As we descend each level, the next
element in the chain for this level is sometimes the same as the one we
just compared against (and know that the new element is greater than).
Hence we can skip the search on that level and descend to the next. During
world_map this reduces the number of calls into _sweep_line_elt_compare()
by ~2.5% (and when performing trapezoidation on strokes gives a similar
speed up of about 2% - not bad for the addition of a single line.)
Use primitives from cairo-wideint-private.h - in this case it helps to
make the code more readable as well as reduce dependence on native 64bit
integers.
Prefer to use the operations form cairo-wideint-private.h in order to
improve readability and reduce our assumptions on the availability of
64bit integers.
'const' is a stricter form of 'pure' in that functions declared with that
attribute do not access any values other than their arguments (in
contrast to 'pure' which is allowed to read from global memory).
Take advantage of the gcc function attribute 'pure', which tells gcc that
the function result only depends upon its arguments and it has zero side
effects (e.g. it does not clobber memory). This gives gcc greater
opportunity to rearrange and optimize the wideint arithmetic.
We often use the construct:
if (_cairo_int64_lt (A, B)
return -1;
if (_cairo_int64_gt (A, B)
return 1;
return 0;
to compare two large integers (int64, or int128) which does twice the
required work on CPUs without large integer support. So replace it with a
single wideint function _cairo_int64_cmp() and therefore allow
opportunities to both shrink the code size and write a more efficient
comparison. (The primarily motivation is to simply replace each block with
a single more expressive line.)
If the sweep-line is currently on an end-point of a line,
then we know its precise x value and can use a cheaper comparator.
Considering that we often need to compare events at end-points (for
instance on a start event), this happens frequently enough to warrant
special casing.
We need to compare the x-coordinate of a line at a for a particular y,
without loss of precision.
The x-coordinate along an edge for a given y is:
X = A_x + (Y - A_y) * A_dx / A_dy
So the inequality we wish to test is:
A_x + (Y - A_y) * A_dx / A_dy -?- B_x + (Y - B_y) * B_dx / B_dy,
where -?- is our inequality operator.
By construction we know that A_dy and B_dy (and (Y - A_y), (Y - B_y)) are
all positive, so we can rearrange it thus without causing a sign
change:
A_dy * B_dy * (A_x - B_x) -?- (Y - B_y) * B_dx * A_dy
- (Y - A_y) * A_dx * B_dy
Given the assumption that all the deltas fit within 32 bits, we can compute
this comparison directly using 128 bit arithmetic.
