Otherwise, calling cairo_set_user_data(cr, key, 0, 0) many times
causes a long user data array, almost all of whose slots are empty.
It leads to unnecessarily much memory consumption and long execution time of
cairo_set_user_data(cr, key, 0, 0) and cairo_get_user_data(cr, key) after
it.
This issue probably happens since the commit
http://cgit.freedesktop.org/cairo/commit/?id=9341c254a
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Commit 4e3ef57bc8 added
coverage-intersecting-triangles with an incorrect reference and
generator. The test checks the rasterization of two overlapping
triangles in the following position:
. .
|\ /|
| X |
|/ \|
.---.
Since the triangles have both vertical and horizontal sides of size
x/WIDTH, the expected coverage is 3/4 (75%) of (x/WIDTH)^2. The
original code, instead, was checking for a coverage of 0.75*x/WIDTH,
as if one of the sides was always 1 unit long.
The image and xlib backends still suffer from some jitter, caused by
the approximation of the actual coverage by means of sampling. For
this reason their references are still considered XFAIL, even though
their result now looks mostly consistent with the expected reference.
The make-cairo-test-constructors.sh script executes several commands
without checking their success. This can lead to undetected errors,
like those fixed in 86fad78fcd.
The script now exits with an error status if no file is
input. Moreover, it sets the '-e' flag, so that if a command fails,
the whole script is immediately terminated with an error.
In the Makefile.am, the script result is now checked and the target
file is removed upon error. This ensures that the
'cairo-test-constructors.c' target completes succesfully only if no
error occurred.
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Since 70cc8f250b the quartz backend is
using some APIs that are not available on MacOSX 10.4 directly
(i.e. without detecting their availability through dynamic linking).
This means that the quartz backend does not work anymore on MacOSX
10.4 and that the 10.5 SDK (or newer) is needed to build.
files. Because of this, the generated cairo-test-constructor only
contained a few tests and the test suite was thus incomplete.
Original patch by Andrea Canciani <ranma42@gmail.com>
The bug mentioned in KNOWN_ISSUES was fixed in
2b3d8de11a, but the documentation was
not updated. Moreover, the header of KNOWN_ISSUES was 1.10-specific.
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
On AIX 6.1, getdelim() and getline() are not provided by default,
causing a gcc compilation error. With _GETDELIM defined, AIX's stdio.h
header provides definitions for these routines.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=89356
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
CGFontGetGlyphPath was not public and is not available anymore on
modern OSX/iOS systems. The same functionality is available through
the CoreText API since OSX 10.5.
Based on a patch by Simon Cozens.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=84324
Beginning in 1.12, a crash can occur when the win32 surface's image size
does not cover the entire surface (e.g. due to clipping regions).
This patch enlarges the fallback surface created of the amount
necessary not to write past the end of the DIB. It assumes that
Clip applied to an HDC are clamped to (0,0,width,height) of the HDC.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=53121
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
The current code results in trace lines with the source surface being
pushed on the stack two times instead of one:
s1 s1 //ARGB32 48 48 similar-image % s2
Instead of:
s1 //ARGB32 48 48 similar-image % s2
This greatly confuses later commands when the script was replayed,
causing traces for trivial GTK3 programs to be unplayable, usually
yielding the following error:
"invalid value (typically too big) for the size of the input (surface, pattern, etc.)"
Drop the duplicated entry from the trace line printed by the
cairo_surface_create_similar_image() override.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=73580
Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>
With commit e691d242, the xcb backend started parsing the resources, just like
cairo-xlib does. One behavior from cairo-xlib was missing: If no Xft.rgba
property was specified, cairo-xlib defaults to the screen's subpixel order.
This commit brings that last bit of functionality to cairo-xcb (but currently
disabled due to commit e0c0a673).
This commits adds a new array to cairo_xcb_connection_t that contains the
subpixel order for each screen. There is also a new member in cairo_xcb_screen_t
which contains the subpixel order of that screen and which is initialized from
the array when the screen is constructed. With this in place, the
resource-parsing code can just pick the subpixel order from the screen if
needed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Commit 337ab1f8d9 introduced delayed
font destruction to overcome a race, but prevented the correct cleanup
of the font cache.
This caused fonts to stay in the cache and caused a crash in the
api-special-cases (when running the test suite with -f).
Fixes api-special-cases,
https://bugs.freedesktop.org/show_bug.cgi?id=87567
The snapshot takes a reference to the target recording surface in order
to enable it for use by multiple treads. In order to balance this, the
other two sources of recording surface must also take a reference and
for us to release that reference after the replay.
Otherwise, we end up with a memory leak:
==1== 1,392 bytes in 3 blocks are definitely lost in loss record 1 of 7
==1== at 0x4A06BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==1== by 0x4C7042D: _cairo_recording_surface_snapshot (cairo/src/cairo-recording-surface.c:1427)
==1== by 0x4C842BE: _cairo_surface_snapshot_copy_on_write (cairo/src/cairo-surface-snapshot.c:189)
==1== by 0x4C7E7E0: _cairo_surface_detach_snapshot (cairo/src/cairo-surface.c:348)
==1== by 0x4C7E55B: _cairo_surface_detach_snapshots (cairo/src/cairo-surface.c:333)
==1== by 0x4C7E55B: _cairo_surface_flush (cairo/src/cairo-surface.c:1545)
==1== by 0x4C7E6CC: _cairo_surface_finish_snapshots (cairo/src/cairo-surface.c:1017)
==1== by 0x4C7E6CC: cairo_surface_destroy (cairo/src/cairo-surface.c:961)
==1== by 0x4C625A7: cairo_pattern_destroy (cairo/src/cairo-pattern.c:1131)
==1== by 0x4C3FAC6: _cairo_gstate_fini (cairo/src/cairo-gstate.c:225)
==1== by 0x4C3C68C: _cairo_default_context_fini (cairo/src/cairo-default-context.c:75)
==1== by 0x4C3C708: _cairo_default_context_destroy (cairo/src/cairo-default-context.c:93)
==1== by 0x43E576: record_get (cairo/test/record-extend.c:158)
==1== by 0x43E576: record_replay (cairo/test/record-extend.c:173)
==1== by 0x40E22D: cairo_test_for_target (cairo/test/cairo-test.c:929)
==1== by 0x40E22D: _cairo_test_context_run_for_target (cairo/test/cairo-test.c:1532)
==1== by 0x40B6C0: _cairo_test_runner_draw (cairo/test/cairo-test-runner.c:255)
==1== by 0x40B6C0: main (cairo/test/cairo-test-runner.c:937)
Reported-by: Massimo Valentini <mvalentini@src.gnome.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87898
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When running the cairo-test-suite, valgrind reports each of the
registered test as a leak, because they are _list_prepend()'ed, but
the tests list is never _list_free()'d.
Fixes the following valgrind error:
malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
cairo_boilerplate_xmalloc (cairo-boilerplate-system.c:47)
cairo_test_register (cairo-test-runner.c:131)
_cairo_test_runner_register_tests (cairo-test-constructors.c:1112)
main (cairo-test-runner.c:714)
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
The pattern created by cairo_pattern_create_rgb() is owned by the
caller, hence it needs to be released.
Fixes the following valgrind error:
malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
_cairo_pattern_create_solid (cairo-pattern.c:605)
_cairo_pattern_create_in_error (cairo-pattern.c:628)
cairo_pop_group (cairo.c:552)
test_cairo_push_group (api-special-cases.c:157)
preamble (api-special-cases.c:1766)
main (cairo-test-runner.c:228)
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
On 32bit SPARC the scan converter was causing a SIGBUS due to an unaligned
memory access while accessing an int64_t. This memory accessing was to struct
quorem's rem member.
This crash occurred because the tor-scan-converter contains its own
implementation of a memory pool. This implementation only guarantees an
alignment of sizeof(void *), which is less than what a 64 bit type requires on
32bit platforms. This 4 byte alignment is guaranteed, because struct _pool_chunk
(which is the struct that is used for managing free space) contains elements of
that size and so the size of that struct is a multiple of this size as well.
This problem was introduced with commit 03c3d4b7c1.
To fix this problem, this commit introduces a int64_t member to struct
_pool_chunk that marks the beginning of the free data space. Thanks to this, the
compiler ensures proper alignment and sizeof(struct _pool_chunk) becomes a
multiple of 8.
However, previously the end of the struct marked the beginning of the data and
sizeof() was used for correctly calculating offsets to the data section. So,
just adding such a member would work, but would also waste some memory. To avoid
this, this commit also changes the rest of the pool implementation to
accommodate.
Reported-by: Nicolas Setton <setton@adacore.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
If a span length is negative don't go out of bounds processing the fill
data.
Patch thanks to Ilya Sakhnenko <ilia.softway@gmail.com> on mailing list.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
