Fix 'unused-result' warning messages by
- replacing cairo_private to cairo_private_no_warn in the
declaration of the cairo private apis '_cairo_surface_unmap_image',
'_cairo_polygon_add_line', '_cairo_polygon_add_external_edge' and
'_cairo_polygon_add_contour'
- removing cairo_warn for 'render_rows' member function pointer in
'struct _cairo_span_renderer'
Signed-off-by: Ravi Nanjundappa <nravi.n@samsung.com>
This reverts commit fb57ea13e0.
When running cairo-test-suite with the parameter "-a", it also runs each test
with a non-zero device-offset and device-scaling. The above commit influenced
the device-scaling results badly. E.g. some test results ended up with a black
border at the top-most and left-most row that looked like there was an offset of
"0.5" in drawing the image and thus pixels outside of the image were sampled.
This can be seen by the influence that this revert has on the results from
running CAIRO_TEST_TARGET=image ./cairo-test-suite -a:
Before: 31 Passed, 489 Failed [1 crashed, 8 expected], 31 Skipped
After: 225 Passed, 295 Failed [1 crashed, 8 expected], 31 Skipped
Most of the failures that disappeared are from the device-scaling tests.
With such disastrous results on the test suite, this cannot really be usable for
real-world applications.
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
Explains how to use cairo_surface_set_mime_data so that the image always
gets used even if the MIME data cannot be.
Signed-off-by: jimmyfrasche <soapboxcicero@gmail.com>
Replaces documentation of the form "range 0 to 1 less than the number"
with "ranges from 0 to n-1 where n is the number", which is idiomatic
mathematical writing and less ambiguous.
Signed-off-by: jimmyfrasche <soapboxcicero@gmail.com>
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
Commit 44a09f462c fixed a compiler warning, but changed the result of this code.
This is because the old 'for' loop did one more iteration than the new 'while'
loop. Fix this by incrementing the loop counter once before the loop.
Fixes: mesh-pattern mesh-pattern-accuracy mesh-pattern-conical
mesh-pattern-control-points mesh-pattern-fold mesh-pattern-overlap
mesh-pattern-transformed record-mesh
Signed-off-by: Uli Schlachter <psychon@znc.in>
Tested-by: Bryce Harrington <b.harrington@samsung.com>
Commit 503b6b9e2e added a check_composite method to the mask compositor, but
only added it to one of the existing implementations. This commit fixes that.
In cairo-image-compositor.c, there is already a check_composite method which
just returns success for the traps compositor. This commit makes the mask
compositor use that one.
I don't want to say much about cairo-image-mask-compositor.c except that I
wondered why this file and the file above both define a non-static function
called _cairo_image_mask_compositor_get(). In my opinion, that file should just
be deleted, since it confuses e.g. ctags, but I'll let someone else clean this
up.
Fixes 493 crashes in the test suite for the test-mask target.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Tested-by: Bryce Harrington <b.harrington@samsung.com>
$ ./check-doc-syntax.sh
Checking documentation for incorrect syntax
./cairo-types-private.h (148): WARNING: cairo_hash_entry_t: missing 'Since' field (is it a private type?)
./cairo-types-private.h (161): WARNING: cairo_hash_entry_t: not found
./cairo-types-private.h (175): WARNING: cairo_lcd_filter_t: missing 'Since' field (is it a private type?)
./cairo-cache-private.h (85): WARNING: cairo_cache_entry_t: missing 'Since' field (is it a private type?)
./cairo-region.c (857): WARNING: cairo_region_overlap_t: not found
./cairo-raster-source-pattern.c (62): WARNING: SECTION:cairo-raster-source 'Since' field in non-public element
The warnings about missing 'Since' fields are fixed by changing the
documentation comment so that the script can see that these are private types.
The documentation for cairo_region_overlap_t gets moved to cairo.h, just like
e.g. the documentation for cairo_status_t.
The 'Since' field from the SECTION:cairo-raster-source is removed, because this
kind of field is needed on the individual functions and structs, not on the
section.
Thanks to Bryce Harrington for bringing this up!
Signed-off-by: Uli Schlachter <psychon@znc.in>
Tested-by: Bryce Harrington <b.harrington@samsung.com>
This fixes several distcheck errors regarding missing code docs.
The skia backend was added in commit d7faec02, which was included in the
1.10 release.
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
This fixes this set of distcheck errors generating docs:
src/cairo-surface.c:1668: warning: Parameter described in source code
comment block but does not exist. FUNCTION:
cairo_surface_set_device_scale Parameter: sx.
src/cairo-surface.c:1668: warning: Parameter described in source code
comment block but does not exist. FUNCTION:
cairo_surface_set_device_scale Parameter: sy.
src/cairo-surface.c:1668: warning: Parameter description for
cairo_surface_set_device_scale::x_scale is missing in source code
comment block.
src/cairo-surface.c:1668: warning: Parameter description for
cairo_surface_set_device_scale::y_scale is missing in source code
comment block.
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
This adds a number of items to the documentation for which code docs
exist, and also adds sections for cairo-skia and cairo-surface-observer.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48784
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
_cairo_clip_intersect_box() wasn't checking if it was called with the special,
read-only all-clipped clip and thus could have ended up writing to read-only
memory.
References: https://bugs.freedesktop.org/show_bug.cgi?id=75819
Signed-off-by: Uli Schlachter <psychon@znc.in>
This reverts commit a0f556f37f.
The change was clearly wrong now that I read. I was probably
tricked by what was fixed in the follow-up commit
e738079302.
This fixes crash in pixman_image_composite32().
Originally fixed by Yoshitaro Makise.
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
Fixes the following compiler warning:
cairo-gl-surface.c:182:5: warning: enumeration value
‘PIXMAN_a8r8g8b8_sRGB’ not handled in switch
Same fix as done for image in 1d0055078.
Chris Wilson <chris@chris-wilson.co.uk>
This quells this warning:
src/cairo-mesh-pattern-rasterizer.c:731:5: warning: cannot
optimize possibly infinite loops
I guess the compiler's complaining because if vsteps were negative or
equal to UINT_MAX the loop could cycle infinitely. Silly compiler.
Fix as suggested by Chris Wilson <chris@chris-wilson.co.uk>
This quells the following warnings:
src/cairo-xml-surface.c:576:5: warning: passing argument 2 of
‘_cairo_xml_surface_emit_clip_boxes’ discards ‘const’ qualifier from
pointer target type
src/cairo-xml-surface.c:462:1: note: expected ‘struct cairo_clip_t
*’ but argument is of type ‘const struct cairo_clip_t *’
Most of the cairo_xml*emit* routines const their source objects;
these should follow suit.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
We do some evil things in this doc comment by closing a <para> tag further up.
Make sure we reopen it at the end so that gtk-doc's attempt to close it again
doesn't result in an imbalance.
Escape PostScript names of loaded fonts. These can not
contain white spaces and delimiter characters when saving
them to a PostScript file or a PDF file.
Sometimes as a result of rounding errors in matrix transformations the
matrices in ps/pdf output look like:
0.000000000000000061 1 1 -0.000000000000000061 0 842 cm
This patch rounds to zero matrix elements that are very small compared to
other elements in the same matrix.
ctx->vertex_shaders is only CAIRO_GL_VAR_TYPE_MAX large, so we should
abort the loop before the index is equal to CAIRO_GL_VAR_TYPE_MAX.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Similar to 1f4d05b55c
'Fix calling '_cairo_spline_intersect' for in-bounds checking of splines'
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
The _cairo_color_double_to_short() function converts a double
precision floating point value in the range of [0.0, 1.0] to a
uint16_t integer by dividing the [0.0, 1.0] range into 65536
equal-sized intervals and then associating each interval with an
integer.
Under the assumption that an integer i corresponds to the real value i
/ 65535.0 this algorithm introduces more error than necessary as can
be seen from the following picture showing the analogous
transformation for two-bit integers:
+-----------+-----------+-----------+-----------+
0b00 | 0b01 | 0b10 | 0b11
+-----------+-----------+-----------+-----------+
which shows that some floating point values are not converted to the
integer that would minimize the error in value that that integer
corresponds to.
Instead, this patch uses standard rounding, which makes the diagram
look like this:
+-------+---------------+---------------+-------+
0b00 | 0b01 | 0b10 | 0b11
+-------+---------------+---------------+-------+
It's clear that if the values corresponding to the given integers are
fixed, then it's not possible to decrease the resulting error by
moving any of the interval boundaries.
See this thread for more information:
http://lists.freedesktop.org/archives/cairo/2013-October/024691.html
Reference images updated:
pthread-similar.ref.png
record-paint-alpha.ref.png
record90-paint-alpha.argb32.ref
record90-paint-alpha.rgb24.ref.png
xcb-huge-image-shm.ref.png
xcb-huge-subimage.ref.png
All of these have only one-step differences to the old images.
The cairo-xlib backend maintains a mapping form cairo_format_t to xrender
formats. This is done via an array. The size of this array is
CAIRO_FORMAT_RGB16_565 + 1 which evaluates to 5.
However, CAIRO_FORMAT_RGB30 has the numeric value 5, too. Thus, using this value
as an index into the array would actually read the following force_precision
field from cairo_xlib_display_t.
This could be triggered by passing CAIRO_FORMAT_RGB30 to
_cairo_xlib_display_get_xrender_format(). From a quick look, I didn't find any
code which would allow doing this, but neither did I find anything allowing
CAIRO_FORMAT_RGB16_565, so it's better to handle this correctly than assert()ing
for this to never happen.
Signed-off-by: Uli Schlachter <psychon@znc.in>
