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>
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>
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>
$ ./check-doc-syntax.sh
Checking documentation for incorrect syntax
./cairo-pattern.c (3342): ERROR: Will invalid doc id (should be 'cairo_...:')
The proposed changes fixes the warning about the documentation style used in cairo.
Signed-off-by: Ravi Nanjundappa <nravi.n@samsung.com>
malloc(0) needn't return NULL, and on glibc, doesn't. Then we encounter
a loop of the form do { ... } while (--c), which doesn't do quite what
you were hoping for when c is initially 0.
Since there's nothing to swap in this case, just bomb out.
Signed-off-by: Adam Jackson <ajax@redhat.com>
malloc(0) needn't return NULL, and on glibc, doesn't. Then we encounter
a loop of the form do { ... } while (--c), which doesn't do quite what
you were hoping for when c is initially 0.
Since there's nothing to swap in this case, just bomb out.
Signed-off-by: Adam Jackson <ajax@redhat.com>
since the PS Document Structing Conventions impose a 255 character
line limit. PDF does not require wrapping.
pdf-operators is designed to emit the same output for PS and PDF.
Unfortunately some PDF interpreters don't like strings split with
'\\\n' and some PS interpreters don't like strings split with ')('.
So we are forced to make pdf-operators handling string wrapping
differently for PDF and PS.
Bug 85662
$ ./check-doc-syntax.sh
Checking documentation for incorrect syntax
./cairo-pattern.c (3346): ERROR: Will bad line: ' */'
./cairo-pattern.c (3346): ERROR: Will documentation comment not closed with **/
./cairo-pattern.c (3422): ERROR: _cairo_pattern_sampled_area invalid doc id (should be 'cairo_...:')
The warnings are about the documentation style used in cairo
Signed-off-by: Ravi Nanjundappa <nravi.n@samsung.com>
the active edges list must be left sorted at the next possible use
and since full_row does not deal with intersections it is not usable
when there is an intersection in the top half of the next row first
subrow
Reported-and-tested-by: Matthew Leach
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85151
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
New implementations of _cairo_pattern_sampled_area and _cairo_pattern_get_extents
which produce a more accurate bounding box. These do not depend on side-effects
of analyze_filter, can handle different horizontal and vertical scales, filters
wider than 1 for down-scaling, and compute a somewhat tighter bounding box
in most cases.
I removed the pad output of _cairo_pattern_analyze_filter as it is unused.
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
It will not use the fallback if the symbols in the previous patch
are turned on.
Also some code rearrangement to make this resemble the xlib version
more and to remove some suspect bugs. In particular meshes should not
work just because the translation is an integer.
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
Currently these are always false, but if XRender use a pixman that
supports filtering these could be turned on for that version.
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
Fallback is not used if the symbols defined in the previous patch to
indicate if XRender does GOOD/BEST are true.
This patch also includes some changes to take advantage of the fact that
if there is an integer translation analyze_filter will already have set
the filter to NEAREST.
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
Currently these are always false, but if some version of xlib uses
a pixman supporting filtering they could be changed to return true
for that version.
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
The analysis to deterimine if the GOOD filter can be replaced with
the BILINEAR filter is moved to this function so it can be used
by backends other than the image backend.
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
Fixes a make check error.
Checking that .libs/libcairo.so has the same symbol list as cairo.def
126a127
> cairo_lines_compare_at_y
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=84638
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
The quartz-image backend uses _cairo_surface_is_quartz(), which
therefore needs to be made available to it. Fixed as suggested by
Bryce in the referenced bugreport.
References: https://bugs.freedesktop.org/show_bug.cgi?id=84569
Signed-off-by: Andrea Canciani <ranma42@gmail.com>
As pixman uses an accumulation mask, it oversamples neighbouring edges
within a cell. We can reduce the impact of this by eliminating
overlapping triangles/trapezoids from being passed into pixman.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If all the edges start at the very beginning of the whole row, we can
merge them and include check for intersections/endings during the row.
This allows us to enable fast analytic processing for even the very
first row on pixel aligned vertices.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We use two different methods within tor to compute the coverage.
The first is that we iterate over every sample point within the pixel
and see if it is covered. The second is that we look at a whole pixel
and analytically compute the coverage inside (if we have no
intersections within that row).
One side effect of
commit 03c3d4b7c1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Sep 30 08:44:43 2014 +0100
tor: Fix loss of precision from projection onto sample grid
was to compute our X coordinates for the sample locations (offset by
half a subrow) and that in order to compute the analytical pixel
coverage correctly, we therefore need to backstep by half the subrow to
the pixel boundary.
References: https://bugs.freedesktop.org/show_bug.cgi?id=84396
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When updating the quorem between cells, we would lose the overflow
increment as it was only applied locally and not preserved by updating
the quorem.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The goal is to preserve the precision in the gradients of the edges and
only apply the projection into the final cell location. We also include
the half-subrow offset as spotted by Massimo.
References: https://bugs.freedesktop.org/show_bug.cgi?id=84396
Testcase: coverage-rhombus
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is a follow-up patch on top of 150c1e7044
As discussed in the mailing list, http://lists.cairographics.org/archives/cairo/2014-September/025647.html,
check if the surfaces are of particular backend type or not, before proceeding further.
These changes are based on _cairo_surface_is_xlib() and _cairo_surface_is_image()
Signed-off-by: Ravi Nanjundappa <nravi.n@samsung.com>
As the target renderers operate at a different sample resolution then we
use internally for coordinate representation, there is always a potential
for discrepancies in the line gradients when passing around trapezoids.
To overcome this, the protocol specification of trapezoids uses the full
lines and vertical range as opposed to vertices and so long as we always
use the same lines for conjoint trapezoids, they remain abutting in the
rasteriser.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84115
Testcase: bug-84115
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Currently the very first point on the arc will be the first interpreted
location along the spline used to approximate the arc. This will be
close, but not quite the exact point the user intended the arc to run
from, so begin the arc with a line-to the initial point.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Refactor out a cairo_get_locale_decimal_point() routine to handle a case
where localeconv() is not available.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=70492
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
[edit: Condensed cairo_get_locale_decimal_point and conditionalized
locale.h inclusion. -- bryce]
