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>
These routines actually do exist in the source code, and have proper
documentation, so I'm not sure why distcheck dislikes them, but it's
happier without these listed.
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>
The g_type_init() routine was deprecated in glib 2.34. Tested and
verified this conditionalization on glib 2.32 and 2.36. No need to
change version dependencies.
test/any2ppm.c:864:5: warning: ‘g_type_init’ is deprecated
(declared at /usr/include/glib-2.0/gobject/gtype.h:669)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
This silences a warning due to header file deprecated as of libsrvg
2.36.2. Tested and verified this hackaround on librsvg 2.36.4 and
2.36.1. No need to change version dependencies.
In file included from test/any2ppm.c:73:0:
/usr/include/librsvg-2.0/librsvg/rsvg-cairo.h:27:2: warning:
#warning "Including <librsvg/rsvg-cairo.h> directly is deprecated."
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
This quells the following warning:
perf/micro/hatching.c:39:5: warning: cannot optimize loop, the
loop counter may overflow
Width and height aren't going to be negative so enforce it so that the
compiler can do whatever optimization it wants to do.
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.
CSI_STATUS_SUCCESS is defined as equivalent to CAIRO_STATUS_SUCCESS.
We should prefer the former when comparing against csi_status_t
variables, else we'll get a warning:
cairo-script-interpreter.c:637:23: warning: comparison between
‘csi_status_t’ and ‘enum _cairo_status’ [-Wenum-compare]
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
This quells the following warning:
warning: enumeration value ‘LZO’ not handled in switch [-Wswitch-enum]
The LZO enum value is defined and used elsewhere, even if lzo support
isn't available.
This situation might arise if cairo scripts were generated on one system
with lzo, and then replayed on a system without it. For now simply
error out if this occurs.
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
This error enum was added last September when JBIG2 support was added.
Support it as well in the tracing code. This fixes this warning:
trace.c:1544:5: warning: enumeration value
‘CAIRO_STATUS_JBIG2_GLOBAL_MISSING’ not handled in switch [-Wswitch]
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Most likely this is just a theoretical problem since we just checked
feof, but this quells the following warning:
ps-eps.c:216:8: warning: ignoring return value of ‘fgets’, declared with
attribute warn_unused_result [-Wunused-result]
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
As of libsvg 2.35 calling g_type_init() is sufficient.
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
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.
Add test case for https://bugs.freedesktop.org/show_bug.cgi?id=68382
Something has regressed in the recording surface. All the recording
surface based backends lose the alpha from the paint_With_alpha.
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.
