In commit f6843d5cbb
Author: Arpit Jain <jain.arpit@samsung.com>
Date: Mon Jul 6 14:13:06 2015 -0700
xlib: Fix deferencing of uninitialised 'display'
the common error + clenaup path was clumsily fixed to use the right
variable after the error didn't set the local display variable.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Initialising 'display' to NULL and checking before deferencing during display->base.
This patch will check the deferencing of uninitialised 'display' in case,
_cairo_xlib_display_acquire does not return CAIRO_STATUS_SUCCESS.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=87893
Signed-off-by: Arpit Jain <jain.arpit@samsung.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
When you draw (part of) a surface to an XCB surface, the XCB backend will safe
the uploaded part as a snapshot to the input surface. This allows to re-use this
picture in case the same surface is later used again as a source.
However, other backends do not do this and this has caused and/or highlighted
numerous bugs. Just skipping the snapshot fixes or hides these bugs.
Papers-over: https://bugs.freedesktop.org/show_bug.cgi?id=67505
Signed-off-by: Uli Schlachter <psychon@znc.in>
That is if the difference between the origin and the end is bigger than
.5 round up regardless of the coordinates.
Round the difference of the floats instead of rounding the floats then
diff them.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=84396
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
den_det is positive because intersect_lines is called
only after _slope_compare returned > 0 and slope_compare
is returning the sign of den_det
The quadratic-time intersection finder is #if 0-ed out
in src/cairo-bentley-ottman.c, but is unusable even there
since the second commit to that file.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=74779
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Optimizing compilers aggressively remove code that is executed only
after an undefined behaviour occurred.
Also, the difference of two (non char) pointers hides an integer
division that, because the divisor is known at compile time, is
transformed into a multiplication by a pseudo-reciprocal, and in this
case the difference is not always a multiple of the divisor, resulting
in an invalid comparison predicate.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=74779
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
In Hobby's paper it is proved that INTERSECTION events can be
processed in any order by ignoring intersections between edges
non-adjacent in the active edges list.
But with respect to START/STOP events they must be processed in
order. Because START/STOP events have always exact y, it is
sufficient to know whether an integer y intersection is a
default/excess approximation of the exact to properly sort events.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=74779
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Recent versions of GCC/clang feature a new set of compiler intrinsics
for performing atomic operations, motivated by the operations needed to
support the C++11 memory model. These intrinsics are more flexible than
the old __sync_* intrinstics and offer efficient support for atomic load
and store operations.
Having the load appear atomic to the compiler is particular important
for tools like ThreadSanitizer so they don't report false positives on
memory operations that we intend to be atomic.
Patch from Nathan Froyd <froydnj@mozilla.com>
To maintain compatibility with OpenGL ES 2.0, the matrix in
_cairo_gl_shader_bind_matrix() should be manually transposed,
and GL_FALSE passed as the transpose argument to the
glUniformMatrix3fv() call as it is the only valid value for
that parameter in OpenGL ES 2.0.
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Acked-by: "Henry (Yu) Song" <henry.song@samsung.com>
An earlier fix to bug 84324 added a regression in the font size of
canvas text in Inkscape when compiled with the Quartz backend.
Patch from Andrea Canciani
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=84324
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
A common source of error when people are setting up pango on a new
device is when font files don't have the right permissions and cannot
be opened. Cairo was returning out-of-memory before, making the
Pango error message useless.
With this change, cairo will return file-not-found, and pango prints
that out. It's still not ideal; a ENOACCESS equivalent would have
been better.
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>
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>
